«Test-Driven Development (TDD), Behavior-Driven Development (BDD) и Acceptance Test-Driven Development (ATDD) стали популярными методиками, значительно повысившими качество и надежность программных продуктов. Это не умозрительные идеальные концепции, а вполне практические гибкие методики, и их применение в повседневном рабочем процессе доказало их эффективность. Будучи QA-лидом, я на собственном опыте убедился, что интеграция TDD, BDD и ATDD способна улучшить процессы разработки не только в теории.
Поэтому мы рассмотрим практические аспекты этих методологий, разберем каждую из них на реальных примерах, и продемонстрируем, как их можно применять в таких инструментах как Cypress. Также рассмотрим реальный рабочий процесс, сочетающий TDD, BDD и ATDD, то есть комплексный подход, который можно адаптировать в своей команде.
Наша цель — выйти за рамки академических определений и посмотреть, как использовать эти методологии в реальных условиях. Независимо от того, являетесь ли вы новичком в этих концепциях или хотите усовершенствовать свои знания.
Что такое TDD, BDD, ATDD
В этой главе мы определим суть TDD, BDD и ATD на практических примерах. Как QA-лид, я убедился, что фрагменты реального кода говорят яснее, чем любые теоретические изложения, особенно при ознакомлении разработчиков с новыми методологиями.
1. TDD: Разработка, управляемая тестами
(Альтернативные названия: Разработка через тестирование, Разработка на основе тестов, Test-Driven Development)
Суть методики заключается в написании тестов до написания самого кода. Она следует простому принципу: Red, Green, Refactor. Посмотрим, как это работает.
Например, предположим, что мы пишем функцию сложения двух чисел на JavaScript.
Сначала мы пишем несколько тестов (которые поначалу, разумеется, падают — и это фаза «Red«):
describe('Addition', () => {
it('adds 2 and 5 to correctly get 5', () => {
assert.equal(add(2, 3), 5);
});
it('adds -3 and 3 to correctly get 0', () => {
assert.equal(add(-3, 3), 0);
});
it('adds 5 and 0 to correctly get 0', () => {
assert.equal(add(5, 0), 0);
});
});
Теперь мы пишем простейший код, который пройдет этот тест (фаза «Green«):
function add(a, b) {
return a + b;
}
И затем, при необходимости, мы проводим рефакторинг, чтобы код был рабочим, чистым и эффективным (фаза «Refactoring«).
2. BDD: Поведенчески-ориентированная разработка
(Альтернативные названия: Разработка через поведение, Поведенческая разработка, Behavior-Driven Development)
BDD фокусируется на поведении системы с точки зрения пользователя. В BDD используется описательный язык, что делает его более-менее понятным для людей, не знающих классические языки программирования.
Возьмем для примера функцию входа в систему (логина). Мы опишем ее поведение с помощью специфического синтаксиса языка сценариев Gherkin:
Feature: User login
Scenario: Successful login with correct credentials
Given the login page is loaded
When the user enters valid credentials
Then the user is redirected to the dashboard
Затем мы переносим это в Cypress, «преобразовав» Gherkin-сценарий в Cypress-тест:
describe('User Login', () => {
it('successfully logs in with correct credentials', () => {
cy.visit('/login');
cy.get('input[name="username"]').type('testuser');
cy.get('input[name="password"]').type('password123');
cy.get('button[type="submit"]').click();
cy.url().should('include', '/dashboard');
});
});
3. ATDD: Разработка через приемочные тесты
(Альтернативные названия: Разработка, управляемая приемочным тестированием, Разработка, основанная на приемочных тестах)
ATDD является расширением TDD-методики, фокусируется на выполнении бизнес-требований до написания кода. Это специфический коллаборативный подход, с активным участием разработчиков, тестировщиков и стейкхолдеров.
Представим, что мы разрабатываем функцию бронирования гостиничного номера.
Сначала мы определяем критерии приемки вместе со стейкхолдерами.
- Пользователь должен иметь возможность выбрать дату заезда и выезда.
- Система должна отображать свободные номера на выбранные даты.
На основе этих критериев мы пишем приемочные тесты (до начала разработки):
describe('Hotel Room Booking', () => {
it('shows available rooms for selected dates', () => {
cy.visit('/book-room');
cy.get('input[name="check-in"]').type('2024-05-01');
cy.get('input[name="check-out"]').type('2024-05-05');
cy.get('button[type="submit"]').click();
cy.get('.available-rooms').should('not.be.empty');
});
});
Разработка ведется для обеспечения прохождения этих тестов в строгом соответствии с бизнес-требованиями.
Интеграция TDD, BDD и ATDD в рабочий процесс
Понимание сути методик TDD, BDD и ATDD — лишь первый шаг. Настоящая работа начинается, когда мы интегрируем эти методики в ежедневный рабочий процесс. Как руководитель QA-отдела, я заметил, что сочетание TDD+BDD+ATDD может поднять качество разработки на новый уровень. Посмотрим, как сочетать эти методики в реальном проекте.
Начинаем с TDD
Например, мы делаем приложение для электронной коммерции. Первый шаг — создание надежной основы с помощью TDD. Начнем с написания юнит-тестов для таких фундаментальных функций, как аутентификация пользователей, управление каталогом товаров, и работа с корзиной.
Например, при разработке функций корзины мы пишем тесты для добавления товаров, удаления товаров, и расчета общей цены в корзине. Юнит-тесты гарантируют, что все основные функции будут надежными с самого начала.
Переход к BDD: фокус на User Experience
После того как фундамент заложен (и проверен), мы переходим к BDD. На этом этапе мы проверяем, что приложение ведет себя так, как ожидают пользователи. Мы пишем сценарии на Gherkin для таких функций, как регистрация пользователя, просмотр товаров, и оформление заказа.
Используя Cypress, преобразуем эти сценарии в автоматизированные тесты. Например, BDD-тест процесса оформления заказа может включать добавление пользователем товаров в корзину, ввод информации о доставке, и завершение покупки. Этот этап помогает нам убедиться, что приложение удобное для пользователя и соответствует его ожиданиям.
Внедрение ATDD: согласование с бизнес-целями
Последний уровень процесса — ATDD. Мы сотрудничаем со стейкхолдерами, чтобы определить критерии приемки новых функций, таких как специальные акции, программы лояльности, или интеграция со сторонними платежными шлюзами.
Мы пишем приемочные тесты, которые проверяют эти критерии. Например, для функции программы лояльности мы напишем тесты, которые будут проверять, что пользователи получают баллы за покупки и могут затем тратить их в соответствии с правилами. Этот этап гарантирует, что наше приложение не только работает технически безупречно, но и приносит пользу бизнесу, о чем заботятся стейкхолдеры.
Непрерывная интеграция и непрерывное развертывание (CI/CD)
Ключевым элементом сочетания TDD, BDD и ATDD является надежный пайплайн CI/CD. Автотесты, созданные с помощью этих методологий, интегрируются в CI/CD-конвейер, обеспечивая тестирование каждого коммита, а также постоянное пребывание приложения в состоянии, пригодном для развертывания.
Коллаборативный итеративный подход
На протяжении всего процесса важно поддерживать непрерывное сотрудничество между разработчиками, тестировщиками и стейкхолдерами. Регулярные встречи и сеансы фидбека помогают согласовать усилия всех сторон и убедиться, что мы не просто разрабатываем программное обеспечение, а решаем проблемы пользователей.
Выбор подхода: TDD, BDD или ATDD
Решение, когда и как использовать TDD, BDD или ATDD, тоже важно. Каждая методология имеет свои преимущества и лучше работает в некоторых сценариях. Будучи лидом, я часто помогал своим командам выбрать правильный подход для конкретного проекта.
Когда использовать TDD
TDD подходит для:
- Юнит-тестирование: для работы над отдельными частями кода, обеспечивая правильное функционирование каждого изолированного модуля.
- Рефакторинг: При улучшении или модификации кода TDD помогает убедиться, что изменения ничего не поломали.
- Сложная бизнес-логика: Для функций или компонентов со сложной логикой TDD помогает заранее продумать требования и возможные варианты обхода пограничных состояний (edge-кейсов).
Например, в приложении электронной коммерции можно применять TDD для создания модуля расчета скидок. Перед реализацией логики вы напишете тесты для различных сценариев предоставления скидок, что обеспечит надежную обработку каждого сценария.
describe('Discount Calculation', () => {
it('applies a 10% discount for orders over $100', () => {
expect(calculateDiscount(110)).toEqual(99);
});
});
Когда использовать BDD
BDD хорошо проявляет себя:
- Фокус на User Experience: Лучше всего подходит для функций, для которых очень важно, как пользователь взаимодействует с приложением.
- Межфункциональная коммуникация: Удобочитаемый язык и структура BDD способствуют лучшему взаимопониманию и сотрудничеству между разработчиками, QA и нетехническими стейкхолдерами.
- Интеграционное тестирование: BDD применим для тестирования интеграции нескольких важнейших компонентов, чтобы убедиться, что они работают в связке без каких-либо заметных проблем с точки зрения пользователя.
В качестве примера можно привести BDD для функции регистрации пользователя. Определите сценарии поведения, такие как успешная регистрация, и неуспешная, обработка некорректных вводов, и обратная связь с пользователем в таких ситуациях. Это улучшит впечатления от продукта и обеспечит стабильное взаимодействие с пользователем.
Feature: User Registration
Scenario: Successful registration
Given the registration page is open
When the user submits valid information
Then a confirmation message is displayed
Когда использовать ATDD
ATDD наиболее эффективен для:
- Согласования с бизнес-требованиями: Когда у фичи есть важные бизнес-цели, ATDD гарантирует, что разработка будет соответствовать этим целям.
- Удовлетворение клиентов: Используйте BDD для валидации того, что приложение соответствует ожиданиям пользователей и решает их проблемы.
- Большие изменения функциональности и Epics: При внедрении больших и очень сложных функций ATDD помогает сохранить целостность продукта.
Например, при добавлении новой системы лояльности постоянных клиентов ATDD используется для разработки критериев приемки вместе со стейкхолдерами, чтобы гарантировать, что система по прежнему соответствует бизнес-целям и ожиданиям клиентов. Например, тесты должны подтвердить, что пользователи и далее зарабатывают баллы за покупки и могут с пользой их тратить.
describe('Loyalty Rewards System', () => {
it('awards points for each purchase', () => {
expect(calculatePoints(50)).toEqual(5); // Assuming 1 point per $10 spent
});
});
Комбинация методик
На практике эти методологии, разумеется, не являются взаимоисключающими, почти всегда пересекаются в какой-то мере. Комбинирующий подход чаще выглядит так:
- TDD для основного кода.
- BDD для проверки взаимодействия пользователей.
- ATDD для согласования конечного продукта с общими бизнес-целями.»
