TDD и BDD

TDD (или test-driven development) — подход к разработке и тестированию, при котором сначала создаются тесты, которым должен удовлетворять код и только потом его реализация. TDD — процесс итеративный. Добавляя в класс что то новое, вы сначала пишите тест на новый функционал и только потом создаёте минимальное количество кода, реализующее нужное поведение. Ни строчкой больше, ни меньше. Добившись успешного прохождения теста, можно задуматься о качестве кода и сделать его рефакторинг.

Следуя TDD, вы получаете следующие преимущества:

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

BDD (или behavior-driven development) — расширение подхода TDD к разработке и тестированию, при котором особое внимание уделяется поведению системы/модуля в терминах бизнеса(заказчика). Как правило, такие тесты иллюстрируют и тестируют различные сценарии, которые интересны непосредственно клиенту системы. В связи с этим при составлении таких тестов часто используется фреймворки, обладающие синтаксисом, обеспечивающим читаемость тестов не только программистом, но и представителями заказчика.

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

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

К компонентным и формализующим BDD тестам уже не может быть применён итеративный подход TDD. Сами тесты могут не быть такими атомарными и реализация, необходимая для их выполнения, не всегда тривиальна.

23.06.2018