[2/2] ATDD by Example: A Practical Guide to Acceptance Test-Driven Development (ATDD. Разработка программного обеспечения через приемочные тесты) (Рубрика Engineering)
Продолжая рассказ о книге, расскажу про ключевые принципы ATDD, изложенные в ней
1. Коллаборативная спецификация требований. ATDD базируется на совместной работе бизнес-заказчиков, разработчиков и тестировщиков для формулирования тестируемых требований. Цикл состоит из четырех стадий:
- Discuss - обсуждение пользовательских историй
- Distill - выделение критериев приемки
- Develop - разработка
- Demo - демонстрация прототипа Этот подход гарантирует, что все члены команды имеют одинаковое понимание целей. 2. Примеры как основа коммуникации. В ATDD команда использует конкретные примеры для описания поведения системы вместо абстрактных требований. Эти примеры служат живой документацией и должны быть написаны на языке бизнеса, понятном всем участникам процесса. 3. Автоматизация как буквальная интерпретация. Приемочные тесты должны автоматизироваться таким образом, чтобы они буквально отражали описанные примеры. Это означает, что автоматизированные тесты становятся исполняемой документацией, которая всегда актуальна и может служить регрессионным тестированием. 4. Тестирование до написания кода. Подобно TDD, в ATDD тесты создаются до написания продуктивного кода. Это помогает фокусироваться на том, что действительно нужно пользователю, и избегать оверинжиниринга. 5. Формат Given-When-Then. Для описания сценариев часто используется формат Gherkin с конструкциями Given-When-Then. Given описывает начальные условия, When — действия пользователя, Then — ожидаемые результаты. Этот формат делает тесты читаемыми как для технических, так и для нетехнических участников команды. 6. Фокус на бизнес-ценности. В отличие от unit-тестов, приемочные тесты проверяют функциональность с точки зрения пользователя и бизнес-ценности. Они отвечают на вопрос "работает ли система так, как ожидает заказчик", а не "работает ли конкретный метод правильно". 7. Интеграция с процессом разработки. ATDD не заменяет другие практики тестирования, а дополняет их. Он прекрасно сочетается с TDD на уровне модульных тестов, создавая многоуровневую систему обеспечения качества. 8. Постоянная обратная связь. Автоматизированные приемочные тесты обеспечивают постоянную обратную связь о состоянии системы. 9. Чистота и поддерживаемость тестов. Приемочные тесты должны быть написаны чисто и поддерживаемо. Они являются долгосрочными активами проекта и требуют такого же внимания к качеству кода, как и продакшен код. Рефакторинг тестов — неотъемлемая часть процесса. 10. Демонстрация как валидация. Финальная стадия цикла ATDD — демонстрация работающей функциональности заинтересованным сторонам. Это не только показывает результат, но и позволяет получить обратную связь для дальнейших итераций. Демо служит точкой валидации того, что построено именно то, что требовалось.
В итоге, книга ок с точки зрения базы, но требуется обновление в части
- Использования LLM для генерации тестов (подробнее в "Acceptance Test Generation with Large Language Models: An Industrial Case Study")
- Использовании актуального стека (например, Playwright или Cypress).
- Интеграции в процессы CI/CD
P.S. Книга отправляется в booksharing уголок, что расположен в нашем московском офисе на 7 этаже (надеюсь, что она найдет себе новых читателей).
#QA #DevOps #Process #Software #Engineering #AI