ATDD по сравнению с BDD и надлежащим использованием платформы
Я просто вхожу в понятие BDD и слушал разговор Scott Bellware с Пасущимися парнями Кода. Я играл вокруг с SpecFlow некоторые и как он вполне прилично.
Я понимаю различие между ATDD и TDD, как описано в сообщении в блоге, Классифицирующем Инструменты BDD (Управляемый модульным тестом по сравнению с Управляемым Приемочным испытанием) и немного истории BDD, но это приводит меня к вопросу.
Как описано, разве использование не является инструментом BDD (таким как MSpec) просто другая платформа поблочного тестирования? Мне кажется, что это.
Кроме того, это, кажется, предполагает, что с помощью SpecFlow для спецификации более низкие компоненты уровня (такие как репозитории и сервисы) были бы неправильными. Если я могу использовать тот же инструмент и для ATDD и для TDD более низких компонентов уровня, почему не был должен я? Кажется, все еще существуют некоторые расплывчатые строки здесь, что я чувствую, что не совсем понимаю.
3 ответа
Инструмент, ориентированный на истинное поведение, был бы чем-то вроде Cucumber. Мы используем его в моей работе против кода .NET. Это позволяет нам писать функции, которые определяют поведение системы в целом, а затем мы можем выполнять функции и проверять, выполняет ли система то, что мы ожидаем. У нас весь процесс работает очень хорошо.
Существует реализация .net под названием NStep, которая подключается к огурцу по проводному протоколу, она позволяет вам писать определения шагов на C # с использованием лямбда-выражений ... это довольно круто.
Определения шагов выглядят так:
When("^I go to the \"([^\"]*)\" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
var screen = ParseScreen(pageName);
GoToScreen(screen);
World.Browser.Wait(1000);
});
Думаю, ваше понимание соответствует моему. BDD больше подходит для интеграционного тестирования и обычно тестирует вашу систему как конечный пользователь, например:
Given I am an authorised user
When I go to the front page
Then there should be a link to my profile with my username as the link text.
Нет причин не проводить модульное тестирование ваших репозиториев на более детальном уровне. Я считаю, что и то, и другое полезно и уместно.
Разве я не могу использовать обычные инструменты модульного тестирования? BDD - это процесс и менталитет, и поэтому, да, вы можете делать это с помощью любых инструментов (или нет, вы можете написать свой собственный без инструмента, если хотите). Однако у инструментов TDD были определенные допущения, которые вызывают некоторое трение при попытке сделать что-то в стиле BDD. Например, TDD предполагает, что вы тестируете архитектурную единицу программного обеспечения; класс, модуль, услуга. В то время как BDD предполагает, что вы указываете некоторую функциональную часть системы.
Следует ли использовать SpecFlow / Cucumber для описания компонентов нижнего уровня? Во-первых, я думаю, что вопрос немного ошибочен. Вы не склонны описывать компоненты , если только эти компоненты не представляют непосредственно поведение. Я все равно отвечу в том, в чем, по моему мнению, заключается суть вопроса.
Инструменты, ориентированные на рассказ, такие как Cucumber, отлично подходят для обсуждения поведения с точки зрения клиента / пользователя. Это может позволить вам делать спецификации, которые легко доступны неспециалистам. Однако может быть утомительно описывать большие объемы или сложное состояние с помощью этих инструментов.
Модульное тестирование или другие инструменты спецификации, ориентированные на код, такие как rSpec и Machine.Specification, могут быть намного более удобными при работе со сложными или большими настройками состояния. Вы можете использовать различные инструменты, доступные для языков, для управления состоянием. Такие вещи, как наследование и фейки / моки. В Machine.Specification есть несколько хороших подходов к этому для ориентированных на .NET.
Итак, следует ли использовать Cucumber для определения поведения более низкого уровня? Я бы сказал, только если важно иметь высокий уровень видимости для этого конкретного поведения. В моем текущем проекте мы разработали архитектурный компонент для представления определенных частей системы, интенсивно использующих бизнес-правила. Эти компоненты указаны с помощью Cucumber, но большая часть системы покрыта NUnit.
Кстати, SpecFlow действительно хорош и доступен для .NET-людей, которые только начинают знакомиться с BDD, но в конечном итоге вы захотите перейти на полноценный Cucumber + nStep. Экосистема Cucumber ОГРОМНА и полезна. SpecFlow намного меньше.
Кроме того, лямбда-синтаксис, предлагаемый nStep, немного лучше, чем необходимость декорировать методы в стиле SpecFlow или Cuke4Nuke.
Заявление об ограничении ответственности / Справочная информация: Я выполнял некоторую часть первоначальной разработки на nStep, но в моем текущем проекте я использую SpecFlow. Я работаю над тем, чтобы представить здесь BDD, и мне нужно было что-то простое и доступное.