Инструмент, ориентированный на истинное поведение, был бы чем-то вроде Cucumber. Мы используем его в моей работе против кода .NET. Это позволяет нам писать функции, которые определяют поведение системы в целом, а затем мы можем выполнять функции и проверять, выполняет ли система то, что мы ожидаем. У нас весь процесс работает очень хорошо.

http://cukes.info/

Существует реализация .net под названием NStep, которая подключается к огурцу по проводному протоколу, она позволяет вам писать определения шагов на C # с использованием лямбда-выражений ... это довольно круто.

Определения шагов выглядят так:

When("^I go to the \"([^\"]*)\" (?:[Ss]creen|[Pp]age)$", (string pageName) =>
{
    var screen = ParseScreen(pageName);
    GoToScreen(screen);
    World.Browser.Wait(1000);
});

http://github.com/clearwavebuild/nStep

Я думаю, что ваше понимание соответствует моему. 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, и мне нужно было что-то простое и доступное.

Интересно, что в этом блоге о классификации инструментов BDD рассказывается о TDD и ATDD. Как отмечает Лиз Кеог: BDD - это разговор и исследование. Чем проще для всех вовлеченных людей внести свой вклад, выразить намерения, поделиться идеями, понять других и т. Д., Тем быстрее мы придем к адекватному решению и тем более качественное программное обеспечение мы создадим. Когда мы, наконец, пойдем по пути инструмента, какие инструменты лучше всего поддерживают сотрудничество между участниками программных проектов?

На основании этого блога о различиях между TDD и BDD, и ATDD. Я бы сказал, что существует как минимум три различных варианта инструмента BDD:

1. Фреймворки для модульного тестирования

JUnit изменил наш взгляд на разработку и тестирование. Одна из его сильных сторон заключается в том, что тесты могут быть написаны на том же языке программирования, что и само приложение. Таким образом, мы можем опираться на знания, которые у нас уже есть в команде доставки. Когда тесты используются даже для стимулирования разработки, мы попадаем в рай TDD.

Языки программирования были оптимизированы для уменьшения избыточности, что, по словам Рона Джеффриса, является одним из худших грехов разработчиков. Поэтому мы часто полагаемся на эти инструменты при техническом тестировании, чтобы создать правильный продукт, поскольку они помогают нам работать максимально эффективно.

Несколько парней пытались сделать автоматические тесты более понятными, поскольку модульные тесты на самом деле не читаются. Одной из первых попыток было проанализировать модульные тесты и предоставить краткое резюме, доступное для чтения не разработчикам. Например, TestDox / AgileDox создает простую документацию из имен методов тестовых классов JUnit или Pickels создает документацию на основе файлов функций, написанных на Gherkin.

Такие платформы, как MSpec, помогают писать тесты, которые лучше читаются и дополнительно обеспечивают читаемый вывод. Этот вид инструментов BDD ориентирован на удобочитаемый вывод, что позволяет привлекать не разработчиков после того, как разработчики выполнили свою работу.

2. Системы тестирования сценариев

Чтобы вовлечь заинтересованные стороны на более раннем этапе цикла разработки, были созданы новые инструменты, которые больше ориентированы на читаемый ввод. Cucumber использует простые текстовые файлы для предоставления удобочитаемых данных для автоматизированных тестов. Текстовые файлы содержат сценарии, написанные на особым образом структурированном языке, основанном на структуре «дано когда-то». Эти фреймворки - отличные инструменты, которые поддерживают совместное определение критериев приемлемости.

3. Рамки приемочного тестирования

Параллельно с идеей BDD был разработан другой вид инструментов, одним из первых представителем которых был FIT. Эта платформа для интегрированного тестирования позволяет указывать примеры в таблицах, которые встроены в документацию, относящуюся к Примеры. Для написания этих документов не требуются навыки разработки, и они могут быть легко прочитаны и проверены нетехническими специалистами, поскольку они основаны исключительно на тексте. Кроме того, текст может быть структурирован, поскольку документы представляют собой не простые текстовые файлы, а результат работы многофункциональных редакторов.

FitNesse позволяет совместно определять ожидаемое поведение на основе вики. Поскольку вики-сайты просты в доступе и использовании, они не требуют больших затрат времени для входа и обучения, что способствует совместной работе всей команды. Многие сторонники Agile подчеркивают, что лучший способ сотрудничества - это личное общение. Но если вы записываете то, что думали и обсуждали, это должно быть как можно более богатым и хорошо структурированным.

Concordion обеспечивает большую гибкость, поскольку вы можете описывать свои требования на обычном языке, используя абзацы, таблицы и правильную пунктуацию. Любая часть вашего описания может использоваться в качестве входных данных для ваших автоматических тестов и для проверки результатов вашей тестируемой системы. Поскольку он основан на HTML, вы можете структурировать свои документы и интегрировать изображения. Просто у вас есть выразительность Интернета, чтобы описать ожидаемое поведение.

BDD должен помочь создать правильный продукт

Вы можете реализовать BDD со всеми тремя видами инструментов, но у каждого из них есть свои сильные и слабые стороны. Фреймворки для модульного тестирования и инструменты, подобные xSpec, отлично используют сильные стороны программирования. Поскольку они являются инструментами от разработчиков для разработчиков, они являются идеальным выбором, если вы попытаетесь разобраться в технической части.

Если вы хотите сообщить о намерении приложения, вам, вероятно, будет лучше использовать инструмент, который тесно связан с инструментами, которые редакторы используют в своей работе. Если спецификация содержит только входные данные и ожидаемые выходы, любой, кто ее прочитает, должен будет реконструировать свои идеи по отношению входных данных к ожидаемым выходным данным. Краткое описание цели спецификации в заголовке помогает читателю понять структуру спецификации. Документы, основанные на конкретной спецификации, могут выглядеть так:

Да, SpecFlow - это круто, NSpec - круто ...

FitNesse и Concordion тоже классные