Разработка через тестирование против разработки через поведение в React

"Назад"

27 марта 2023 г. · 10 минут чтения

Тестирование — важнейший аспект разработки программного обеспечения, гарантирующий, что приложения работают должным образом и соответствуют ожиданиям пользователей. В мире React две популярные методологии тестирования приложений — разработка через тестирование (TDD) и разработка через поведение (BDD). В этой статье мы рассмотрим, что такое TDD и BDD, их ключевые отличия, как их можно применять в React для повышения качества и надежности вашего кода, а также рекомендации по выбору правильного подхода к тестированию для проекта. Независимо от того, являетесь ли вы опытным разработчиком React или только начинаете, эта статья предоставит ценную информацию о мире тестирования программного обеспечения в React. Давайте прыгнем прямо в это!

Разработка через тестирование в React

Разработка через тестирование (TDD) — это подход к разработке программного обеспечения, при котором тесты пишутся до написания кода. Тесты направляют процесс разработки, гарантируя соответствие кода заданным требованиям. В TDD тесты запускаются после каждого изменения, внесенного в код, что упрощает выявление и исправление любых ошибок или проблем на ранних этапах процесса разработки. Вот рабочий процесс процесса TDD в React:

Напишите тест: разработчик пишет тест, который определяет, что должен делать код, и тест должен быть написан до того, как будет написан фактический код.
Запустите тест: тест запускается, чтобы увидеть, не провалится ли он, что и должно быть, потому что еще нет кода, чтобы заставить его пройти.
Напишите код: разработчик пишет код, чтобы пройти тест.
Повторно запустите тест: тест запускается повторно, чтобы убедиться, что он проходит с новым кодом.
Рефакторинг кода. При необходимости код можно рефакторить, чтобы сделать его более эффективным или удобным в сопровождении, но тесты все равно должны пройти.
Повтор: этот процесс повторяется для каждого теста, который необходимо написать.

TDD помогает гарантировать, что код соответствует заданным требованиям, и помогает выявлять любые ошибки или проблемы на ранних этапах процесса разработки. Это делает процесс разработки более эффективным и снижает потребность в отладке и тестировании на более поздних этапах процесса.

Преимущества TDD в React

Вот некоторые из преимуществ разработки через тестирование в React:

Улучшенное качество кода: TDD требует, чтобы разработчики писали тесты перед фактическим кодом, что помогает гарантировать, что код соответствует заданным требованиям. Это уменьшает количество багов и ошибок, что приводит к улучшению качества кода. Сосредоточив внимание на написании тестов, определяющих желаемое поведение, TDD заставляет разработчиков думать о требованиях до написания кода, что помогает выявлять проблемы на ранних этапах процесса разработки. Это может сэкономить время и усилия при отладке и устранении проблем.
Быстрая разработка: TDD помогает сделать процесс разработки более эффективным. Выявляя ошибки и проблемы на ранней стадии, разработчики могут быстро их исправить, не тратя много времени на отладку и тестирование позже. Запуск тестов после каждого изменения помогает убедиться, что код остается функциональным, а новые изменения не нарушают существующую функциональность. Это может помочь ускорить процесс разработки и сократить время, необходимое для завершения проекта.
Простота обслуживания. Тесты направляют процесс разработки, упрощая поддержку кода с течением времени. Если в код вносятся изменения, тесты можно использовать для проверки того, что код по-прежнему соответствует требованиям. Это может помочь снизить риск появления ошибок или нарушения существующей функциональности при внесении изменений в код. Тесты также могут служить документацией для кода, облегчая другим разработчикам понимание кода и его требований.
Улучшенная документация: тесты служат документацией для кода, облегчая другим разработчикам понимание кода и его требований. Тесты написаны таким образом, чтобы определить желаемое поведение, чтобы другим было проще увидеть, что должен делать код. Это может помочь уменьшить потребность в дополнительной документации, облегчая другим разработчикам быстрое ознакомление с программой.
Повышение уверенности: TDD помогает повысить уверенность разработчиков в написанном ими коде. Запуская тесты после каждого изменения, разработчики могут убедиться, что код работает и соответствует требованиям. Это может снизить риск появления ошибок или нарушения существующей функциональности и дать разработчикам уверенность в том, что они могут вносить изменения в код, не опасаясь возникновения проблем.

Пример: допустим, вы создаете компонент React, который отображает форму и получает информацию от пользователя. Используя TDD, наш процесс разработки будет выглядеть так:

Написание теста. Начнем с написания теста, определяющего, что должен делать компонент. Например, тест будет выглядеть так:

describe("Contact form in App.js", () => {
  it("renders the form with correct labels and inputs", () => {
    const { getByLabelText, getByRole } = render(<App/>);

    expect(getByLabelText("Name:")).toBeInTheDocument();
    expect(getByLabelText("Email:")).toBeInTheDocument();
    expect(getByLabelText("Message:")).toBeInTheDocument();
    expect(getByRole("textbox", { name: "Name:" })).toBeInTheDocument();
    expect(getByRole("textbox", { name: "Email:" })).toBeInTheDocument();
    expect(getByRole("textbox", { name: "Message:" })).toBeInTheDocument();
});

    it("displays errors for empty fields", () => {
    const { getByText, getByRole } = render(<App/>);
    const submitButton = getByRole("button", { type: "submit" });
    fireEvent.click(submitButton);

    expect(getByText("Name is required")).toBeInTheDocument();
    expect(getByText("Email is required")).toBeInTheDocument();
    expect(getByText("Message is required")).toBeInTheDocument();
  });
})

Проверка того, что тест не пройден. Затем мы запустим тест, чтобы убедиться, что он не пройден, потому что компонент еще не существует. Это важный шаг в TDD, поскольку он гарантирует, что мы четко понимаем, что должен делать тест.

Написание кода: после того, как тест будет написан, мы напишем код, чтобы пройти тест. Компонент может выглядеть примерно так:

Проверка прохождения теста: после написания кода мы повторно запускаем тест, чтобы убедиться, что он проходит. Если тест пройден, компонент соответствует заданным требованиям.

Рефакторинг кода. При необходимости мы можем провести рефакторинг кода, чтобы сделать его более эффективным или удобным в сопровождении, но наши тесты проходят успешно, поэтому нам не нужно рефакторить наш код.

Следуя этому процессу, мы можем быть уверены, что код соответствует указанным требованиям и работает. Тесты служат документацией для кода, облегчая другим разработчикам понимание того, что он должен делать. Тесты также помогают выявлять любые ошибки или проблемы на ранних этапах процесса разработки, экономя время и усилия при отладке и устранении проблем позже.

Разработка, управляемая поведением (BDD) в React

Behavior-Driven Development (BDD) — это подход к разработке программного обеспечения, который делает упор на сотрудничество между разработчиками, заинтересованными сторонами и бизнес-группами для понимания и определения поведения создаваемой системы. BDD включает в себя написание удобочитаемых сценариев или примеров, которые описывают, как система должна вести себя в определенных ситуациях. Затем эти сценарии превращаются в автоматические тесты, которые проверяют поведение системы по мере ее разработки. Цель BDD — обеспечить общее понимание создаваемой системы и способствовать лучшему общению и сотрудничеству между командой разработчиков и заинтересованными сторонами. Шаги процесса BDD в React следующие:

Определение сценариев. Первым шагом в BDD является создание четких и кратких сценариев, описывающих ожидаемое поведение системы с точки зрения пользователя. Эти сценарии должны быть написаны простым языком и отражать желаемое поведение в конкретных ситуациях. Цель состоит в том, чтобы иметь общее понимание строящегося поведения.
Превратите сценарии в тесты. После определения сценариев следующим шагом будет преобразование их в автоматические тесты. Обычно это делается с помощью среды тестирования BDD, такой как Cucumber или SpecFlow. Эти тесты должны быть написаны так, чтобы их было легко понять и их могли прочитать как команда разработчиков, так и заинтересованные стороны.
Напишите код. После того, как тесты готовы, следующим шагом будет написание кода, обеспечивающего их прохождение. Код должен быть написан таким образом, чтобы он соответствовал требованиям, указанным в тестах. Крайне важно убедиться, что код соответствует определенным требованиям, прежде чем переходить к следующему шагу.
Запуск тестов. После того, как код написан, запускаются тесты, чтобы проверить, пройдены ли они. Если тесты пройдены, код соответствует требованиям, определенным в тестах, и ведет себя так, как ожидалось.
Рефакторинг кода. При необходимости код можно реорганизовать, чтобы сделать его более эффективным, удобным для чтения или сопровождения. Однако важно повторно запустить тесты после рефакторинга, чтобы убедиться, что код по-прежнему соответствует требованиям и ведет себя так, как ожидалось.
Повторите процесс. Повторите описанные выше шаги для каждого сценария, который необходимо реализовать. Это может включать в себя написание тестов для дополнительных компонентов, функций или любой другой единицы кода.

BDD обеспечивает четкий и лаконичный подход к разработке программного обеспечения, помогая гарантировать, что создаваемая система соответствует требованиям и ведет себя так, как ожидается. Это также способствует сотрудничеству и общению между командой разработчиков и заинтересованными сторонами, помогая гарантировать, что все находятся на одной волне на протяжении всего процесса разработки. Вот пример BDD в React:

Определите сценарий. Предположим, мы хотим написать тесты BDD для списка покупок. сценарий можно определить следующим образом: «Учитывая, что пользователь посещает список магазинов, если в списке нет продуктов, то ни один продукт не должен отображаться, если есть продукты, то эти продукты отображаются, если у этих продуктов есть цены, то они должны быть отображаются с их ценами».
Превратите наш сценарий в тесты. Сценарий можно превратить в автоматизированные тесты с помощью среды тестирования BDD, такой как шутка-огурец. Тесты могут быть написаны таким образом, чтобы их было легко понять команде разработчиков и заинтересованным сторонам. Например, используя синтаксис Gherkin:

Feature: My Cart

    Scenario: List products with no products
        When I list products
        Then there should be 0 products

    Scenario: List products
        Given there is a product "Toothpaste"
        And there is a product "Shoes"
        When I list products
        Then there should be 2 products

    Scenario: List products names
        Given there is a product "Toothpaste"
        And there is a product "Shoes"
        When I list products
        Then there should be the "Toothpaste" product
        And there should be the "Shoes" product

    Scenario: List products shows prices
        Given there is a product "Toothpaste" with price $19
        And there is a product "Shoes" with price $29
        When I list products
        Then there should be the "Toothpaste" product with price $19
        And there should be the "Shoes" product with price $29

Напишите код. Теперь, когда тесты готовы, следующим шагом будет написание кода, который обеспечит их прохождение. Код может включать в себя создание компонента формы входа в React, подключение к API аутентификации для проверки учетных данных пользователя и обработку перенаправлений и сообщений об ошибках на основе ответа от API. Вы можете получить код формы из репозитория

Запуск тестов. После того, как код написан, запускаются тесты, чтобы проверить, пройдены ли они. Если тесты пройдены, это означает, что код соответствует требованиям, определенным в тестах, и ведет себя так, как ожидалось.

Рефакторинг кода. При необходимости код можно реорганизовать, чтобы сделать его более эффективным, удобным для чтения или сопровождения. Однако очень важно повторно запустить тесты после рефакторинга, чтобы убедиться, что код по-прежнему соответствует требованиям и ведет себя так, как ожидалось.
Повторите процесс: повторите описанные выше шаги для дополнительных сценариев по мере необходимости.

BDD помогает гарантировать, что создаваемая система соответствует требованиям и ведет себя так, как ожидается, а также способствует сотрудничеству и общению между командой разработчиков и заинтересованными сторонами.

Повтор сеанса для разработчиков

Раскройте разочарования, выявите ошибки и устраните замедления работы, как никогда раньше, с помощью OpenReplay — набора для воспроизведения сеансов с открытым исходным кодом для разработчиков. Его можно разместить самостоятельно за несколько минут, что дает вам полный контроль над данными клиентов.

Удачной отладки! Попробуйте использовать OpenReplay сегодня.

Сравнение TDD и BDD в React

И TDD, и BDD имеют свои преимущества и недостатки, и выбор между ними в конечном итоге зависит от конкретных потребностей и целей проекта. В этом разделе мы сравним TDD и BDD, выделим их сходства и различия и поможем вам принять обоснованное решение о том, какой подход лучше всего подходит для вашего проекта React.

Сходства и различия

Вот некоторые сходства между TDD и BDD в React:

И TDD, и BDD подчеркивают важность тестирования в процессе разработки. Они гарантируют, что код тщательно тестируется перед развертыванием, чтобы предотвратить появление ошибок и других проблем в рабочей среде.
Оба подхода направлены на то, чтобы сделать процесс разработки более эффективным и снизить риск ошибок и других проблем. Это достигается ранним и частым тестированием кода и устранением проблем сразу после их обнаружения.
Чтобы эффективно использовать TDD или BDD в React, необходимо четкое понимание требований и целей проекта. Это включает в себя наличие хорошо разработанного плана тестирования, в котором указано, что и как следует тестировать.
И TDD, и BDD требуют сотрудничества между разработчиками, тестировщиками и заинтересованными сторонами, чтобы гарантировать учет всех точек зрения. Это помогает гарантировать, что тесты точно отражают требования проекта.
Инструменты автоматизированного тестирования играют ключевую роль как в TDD, так и в BDD. Эти инструменты упрощают быстрое и эффективное выполнение тестов и обеспечивают более быструю обратную связь об успешном или неудачном выполнении тестов.
TDD и BDD можно использовать для тестирования различных компонентов, сервисов и других элементов приложения React. Это помогает гарантировать, что приложение работает должным образом и любые изменения, внесенные в код, не нарушают существующие функции.

Несмотря на многие сходства, TDD и BDD различаются по-разному, например;

Подход. TDD (разработка через тестирование) — это подход, при котором разработчики пишут тесты перед написанием кода. Целью TDD является проверка того, что отдельные блоки кода работают должным образом и что изменения в коде не нарушают существующую функциональность. С другой стороны, разработка на основе поведения (BDD) — это подход, который фокусируется на написании тестов, описывающих поведение разрабатываемой системы. Цель BDD — подтвердить, что система в целом ведет себя так, как ожидается.
Структура теста. Тесты TDD написаны в виде кода и используют технический язык. Обычно они пишутся разработчиками и предназначены для проверки реализации кода. Тесты TDD относятся к более низкому уровню и сосредоточены на проверке того, что отдельные блоки кода работают должным образом. С другой стороны, тесты BDD написаны на естественном языке и призваны облегчить понимание нетехническими заинтересованными сторонами. Тесты BDD относятся к более высокому уровню и направлены на проверку поведения системы в целом. Это делает тесты BDD более подходящими для совместной работы разработчиков, тестировщиков и заинтересованных сторон.
Фокус на тестировании: TDD фокусируется на проверке реализации кода. Тесты TDD больше касаются того, как написан код, и направлены на проверку того, что отдельные блоки кода работают должным образом. С другой стороны, BDD фокусируется на проверке поведения системы. Тесты BDD больше касаются того, что делает код, и направлены на проверку того, что система в целом ведет себя так, как ожидалось.
Тестовая документация. Тесты TDD обычно используются в качестве документации для тестируемого кода. Они обеспечивают запись поведения отдельных единиц кода и помогают разработчикам понять, как работает код. С другой стороны, тесты BDD написаны для более полного понимания поведения разрабатываемой системы. Тесты BDD дают четкое представление о поведении системы на высоком уровне, облегчая заинтересованным сторонам понимание поведения системы.
Автоматизация тестирования: автоматизированное тестирование является важным аспектом как TDD, так и BDD. Тесты TDD часто автоматизируются на более низком уровне, сосредотачиваясь на отдельных единицах кода. Тесты BDD, с другой стороны, автоматизированы на более высоком уровне, обеспечивая более полное понимание поведения системы в целом. Автоматизированное тестирование необходимо как для TDD, так и для BDD, поскольку оно обеспечивает последовательное и точное выполнение тестов.
Отзывы о тестировании. Тесты TDD обеспечивают быструю обратную связь об успешности или неудаче отдельных блоков кода. Это делает тесты TDD хорошо подходящими для тестирования отдельных блоков кода, поскольку разработчики могут быстро выявлять и устранять любые проблемы. С другой стороны, тесты BDD дают более полное представление о поведении системы в целом. Тесты BDD лучше подходят для тестирования сложных систем, поскольку они дают четкую картину поведения системы на высоком уровне. Это упрощает выявление и устранение любых проблем с системой в целом.

За и против

В этом разделе, начиная с TDD, мы рассмотрим преимущества и недостатки использования TDD и BDD в разработке React. Вот некоторые преимущества TDD в разработке:

Раннее обнаружение ошибок. Поскольку разработчики пишут тесты до написания фактического кода, это помогает обнаруживать ошибки и ошибки на ранних этапах процесса разработки.
Улучшенное качество кода. Поскольку разработчики сначала пишут тесты, они гарантируют, что код написан таким образом, чтобы он удовлетворял всем требованиям.
Улучшенная документация. Написание тестов может служить документацией и облегчать понимание кода другими разработчиками.
Повышение уверенности в рефакторинге: TDD упрощает рефакторинг кода, поскольку у разработчиков есть набор тестов, которые могут гарантировать, что изменения не нарушат какие-либо существующие функции.
Ускоренная разработка: TDD может ускорить разработку, поскольку разработчики пишут только минимальный код, необходимый для прохождения теста, что делает процесс более целенаправленным и эффективным.

Разработка через тестирование — отличный подход к разработке, но есть несколько недостатков, о которых стоит упомянуть:

Занимает много времени. Написание тестов перед написанием фактического кода может занять много времени, особенно для крупных проектов со сложными требованиями. Кроме того, написание тестов может быть более сложным процессом, чем написание кода, поскольку они должны охватывать все сценарии и пограничные случаи.
Крутая кривая обучения: TDD требует другого мышления и подхода к разработке и может быть сложной задачей для разработчиков, не знакомых с практикой. Разработчики должны научиться думать о своем коде с точки зрения тестов и требований и соответствующим образом корректировать свои процессы разработки.
Избыточная инженерия: TDD может привести к чрезмерной инженерии, поскольку разработчики могут написать больше тестов, чем необходимо, усложняя и замедляя процесс разработки. Кроме того, написание слишком большого количества тестов может затруднить поддержку набора тестов с течением времени.
Негибкость. TDD может быть негибким, поскольку разработчики должны писать тесты перед написанием кода, что затрудняет адаптацию к изменениям в требованиях или дизайне. Это может привести к жесткому процессу разработки, который трудно изменить по мере развития требований.

Обсудив плюсы и минусы TDD, давайте теперь углубимся в преимущества и недостатки Behavior Driven Development (BDD) в React.

Ориентирован на взаимодействие с пользователем. В BDD тесты написаны простым английским языком, что облегчает понимание того, чего хочет пользователь и что должно делать программное обеспечение. Это означает, что программное обеспечение будет создано с учетом опыта пользователя, что с большей вероятностью удовлетворит его потребности.
Улучшает сотрудничество: BDD поощряет сотрудничество между различными командами и отделами, включая разработчиков, тестировщиков и заинтересованных лиц. Это означает, что каждый может сказать, что должно делать программное обеспечение и как оно должно работать. Это приводит к лучшему общению и пониманию, что в конечном итоге приводит к лучшему продукту.
Повышенная читабельность тестов. Поскольку тесты BDD написаны на простом английском языке, их легче понять всем, кто участвует в процессе разработки. Это означает, что тесты более удобны в сопровождении и менее подвержены ошибкам, поскольку все понимают, что они проверяют.
Поддерживает непрерывную интеграцию и доставку. Тесты BDD можно автоматизировать и интегрировать в процесс разработки, что упрощает развертывание программного обеспечения, делает его более быстрым и надежным. Это означает, что баги и ошибки могут быть обнаружены на ранней стадии, а программное обеспечение может быть доставлено пользователю быстрее.

Разработка, основанная на поведении, дает много преимуществ, но вот несколько недостатков BDD в React:

Более медленный цикл обратной связи. Написание тестов BDD, описывающих поведение приложения, может занять больше времени, чем написание тестов TDD, ориентированных на отдельные функции или компоненты. В результате цикл обратной связи для BDD может быть медленнее, и для выявления и устранения проблем в коде требуется больше времени.
Более сложные наборы тестов. Тесты BDD предназначены для удобочитаемости и обеспечивают четкое описание поведения приложения. Однако это происходит за счет увеличения сложности набора тестов. Тесты BDD могут быть более сложными в написании и обслуживании, чем тесты TDD, особенно для команд с меньшим опытом в BDD.
Увеличение использования ресурсов. Для тестов BDD часто требуются специализированные инструменты и среды тестирования, что может увеличить стоимость и сложность разработки. Эти инструменты и фреймворки также могут добавить уровень абстракции, который может затруднить понимание базового кода и того, как он работает.
Ограниченная возможность повторного использования: тесты BDD написаны для многократного использования и обеспечивают четкое понимание поведения приложения. Однако такой акцент на поведении может ограничить их полезность для технических тестов, например, для тестирования производительности или масштабируемости.
Уменьшение внимания к коду. Тесты BDD сосредоточены на описании поведения приложения, а не лежащего в его основе кода. Хотя это обеспечивает четкое понимание поведения, иногда это может привести к уменьшению внимания к коду и тому, как он работает. Это может усложнить выявление и устранение проблем в коде, а также оптимизацию и повышение производительности.

Выбор между TDD и BDD в React

В этом разделе мы рассмотрим факторы, которые следует учитывать при выборе между TDD и BDD в разработке React. Цель состоит в том, чтобы помочь разработчикам принять обоснованное решение о подходе, который лучше всего соответствует потребностям и требованиям их проекта.

При выборе между TDD и BDD при разработке React следует тщательно учитывать следующие факторы:

Объем проекта и требования. Размер и сложность проекта определяют тип используемого подхода к тестированию. Для больших и сложных проектов предпочтительным выбором может быть BDD, поскольку он помогает отслеживать требования и поведение. TDD может подойти для небольших проектов.
Экспертиза и опыт команды. На выбор подхода могут повлиять знания и опыт команды. TDD требует глубокого понимания реализации и технических деталей, тогда как BDD больше ориентирован на поведение и может быть легче для понимания членами команды, не являющимися техническими специалистами.
Удобочитаемость и ремонтопригодность тестов. Удобочитаемость и ремонтопригодность тестов являются решающими факторами при выборе подхода. Тесты TDD могут быть более техническими и трудными для понимания, в то время как тесты BDD написаны простым языком и более читабельны.
Интеграция с другими инструментами и технологиями. Интеграция с другими инструментами и технологиями может повлиять на выбор подхода. TDD проще интегрировать с инструментами тестирования, тогда как BDD может потребовать дополнительной настройки.
Скорость обратной связи. Скорость обратной связи является важным фактором в процессе разработки. TDD может обеспечить более быструю обратную связь, поскольку фокусируется на реализации, в то время как BDD может потребовать больше времени, поскольку фокусируется на поведении.
Тестовая документация. Тестовая документация имеет решающее значение для понимания тестов и обеспечения их сопровождения. Тесты TDD могут предоставить ограниченную документацию, в то время как тесты BDD написаны простым языком и предоставляют более подробную документацию.
Сосредоточьтесь на поведении или реализации: TDD фокусируется на реализации и гарантирует, что код работает должным образом, а BDD фокусируется на поведении и обеспечивает соответствие кода требованиям. Разработчики должны выбирать подход, основанный на том, что они предпочитают.
Ограничения по стоимости и времени. Ограничения по стоимости и времени проекта могут повлиять на выбор подхода. TDD может быть быстрее и дешевле, в то время как BDD может занимать больше времени и денег из-за дополнительного внимания к поведению и документации.
Предпочтение методологии разработки: предпочтение методологии разработки команды может повлиять на выбор подхода. TDD хорошо согласуется с методологиями Agile и DevOps, а BDD хорошо согласуется с водопадом и другими традиционными методологиями.

Заключение

TDD и BDD являются ценными методологиями тестирования для разработки React, каждая из которых предлагает свой набор преимуществ и проблем. В конечном итоге выбор между TDD и BDD зависит от конкретных потребностей и целей вашего проекта, а также предпочтений вашей команды. Чтобы максимизировать преимущества любого подхода, важно полностью понимать его сильные и слабые стороны, а также факторы, которые следует учитывать при выборе между ними. Независимо от того, выберете ли вы TDD или BDD, уделив время реализации надежной стратегии тестирования, вы сможете создать высококачественное и надежное приложение React, отвечающее потребностям ваших пользователей.