Тест — это процедура, которая позволяет либо подтвердить, либо опровергнуть работоспособность кода. Когда программист проверяет работоспособность разработанного им кода, он выполняет тестирование вручную.
BDD-тесты могут быть написаны, например, техническими менеджерами или тестировщиками, что делает возможным их использование не только при формальной TDD-разработке, но и при составлении компонентных тестов, а также при формализации требований к системе.
Вот какая проблема у меня возникла – используя и обучая таким agile практикам, как разработка через тестирование (test-driven development -TDD), я натыкался на одно и то же непонимание и удивление в совершенно разных проектах. Разработчики хотели знать, где начать, что тестировать и что не тестировать, как много тестировать за один проход, к чему обращаться в тестах и как понять, почему тест обвалился.
Чем больше я углублялся в TDD, тем сильнее я чувствовал, что для меня это скорее не процесс постепенного наращивания мастерства, а серия тупиковых ситуаций. Часто у меня возникала мысль “Если бы мне только кто-нибудь сказал об этом!”, и гораздо реже: “Ура, дверь открылась”. Я решил, что можно представить TDD так, чтобы эта практика приводила к хорошим результатам, и удавалось избежать подводных камней.
Для решения возникающих проблем я создал практику, которая называется «разработка, основанная на функционировании» (behaviour-driven development – BDD). Эта практика эволюционировала из уже установившихся agile практик, и разработана, чтобы сделать их более доступными и эффективными для команд-новичков в agile разработке. Со временем BDD охватила такие области, как agile анализ и автоматизированное приемочное тестирование.
TDD-подход в разработке ПО заслуженно завоевал свое место под солнцем. В течение жизни он постепенно переосмыслялся, переходя из разряда методов для поиска багов в разряд методов для описания архитектуры приложения. Следующим шагом, органично дополняющим эволюционировавший TDD является BDD — Behavior Driven Development.
Суть BDD — в описании системы архитектуры приложения в терминах эксперта предметной области, а не программиста, что позволяет ускорить процесс получения обратной связи и убрать традиционные языковые барьеры между создателями ПО и его пользователями.
С помощью BDD тестировать систему (или, как сейчас принято говорить, описывать сценарии взаимодействия) может не только сам программист, пишущий код, но и PM, не разбирающийся в деталях реализации, но хорошо знающий систему с точки зрения пользователя. Для новичков BDD-скрипты — самый простой и натуральный пусть ознакомиться с документацией проекта.
В последнее время BDD применяется чаще в вебе, по большей части из-за того, что его модель сценариев органично вписывается в принцип «запрос-ответ».
Как это выглядит сейчас
Самыми популярнымы инструментами для работы в стиле BDD являются Cucumber для Ruby и SpecFlow для .NET. Оба они используют язык Gherkin.
@Сценарий использования, вариант использования, прецедент использования (англ. use case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актёра (англ. actor) (может применяться термин Актант[1]), может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования.@
