ATDD против BDD и надлежащее использование фреймворка
Я просто вхожу в концепцию BDD и слушал разговор Скотта Беллвэра с ребятами пастушьего кода. Я немного поиграл со SpecFlow и мне это очень нравится.
Я понимаю различие между ATDD и TDD, как описано в блоге классификация инструментов BDD (модульный тест-драйв против приемочного теста) и немного истории BDD, но это приводит меня к вопросу.
как описано, не использует инструмент BDD (например как MSpec) просто еще одна структура модульного тестирования? Мне кажется, так оно и есть.
кроме того, это, по-видимому, предполагает, что использование SpecFlow для спецификации компонентов нижнего уровня (таких как ваши репозитории и службы) было бы неправильным. Если я могу использовать один и тот же инструмент для ATDD и TDD компонентов более низкого уровня, почему бы и нет? Кажется, здесь все еще есть размытые линии, которые я чувствую, что не совсем понимаю.
5 ответов
Быстрый Ответ
один очень важно точка, чтобы поднять, что есть два вкуса развития, обусловленного поведением. два вкуса xBehave и xSpec.
xBehave BDD: SpecFlow
SpecFlow (очень похоже на огурец из стека Ruby) отлично подходит для облегчения тестов XBEHAVE BDD в качестве критериев принятия. Однако это не обеспечивает хороший способ напишите поведенческие тесты на едином уровне. Есть несколько других рамок тестирования xBehave, но SpecFlow получил много тяги.
xSpec БДД: NSpec
для развития управляемого поведением на уровне блока,Я бы порекомендовал NSpec (непосредственно вдохновлен RSpec Рубина). Вы можете выполнить BDD на уровне единицы измерения, просто используя NUnit или MSTest...но они вроде как не дотягивают (это действительно трудно создать контексты пошагово.) MSpec также является опцией, в нее было вложено много работы, но есть только что-то, что просто более простое в NSpec (вы можете постепенно создавать контекст в MSpec, но для этого требуется наследование, которое может стать сложным).
Длинный Ответ
2 флейвора BDD главным образом существуют из-за ортогональных преимуществ они обеспечивают.
плюсы и минусы xBehave (GWT Синтаксис)
плюсы
- помогает облегчить разговоры с бизнесом через общий диалект под названием (например. С учетом.... И Дано ...., Когда. ..... И Когда ..... , Затем. ... И Тут)
- общий диалект может быть сопоставлен с исполняемым кодом, который доказывает бизнесу, что вы действительно закончили то, что вы сказали, что закончите
- диалект сужается, поэтому бизнес должен устранить неоднозначные требования и сделать его подходящим в предложения.
минусы
- хотя подход xBehave хорош для управления критериями принятия высокого уровня, циклы, необходимые для сопоставления английского языка с исполняемым кодом через атрибуты, делают его невозможным для вытеснения домена на уровне единицы.
- сопоставление общего диалекта с тестами болезненно (увеличьте свое регулярное выражение). Каждое предложение, создаваемое бизнесом, должно быть сопоставлено исполняемому методу с помощью атрибутов.
- в общий диалект должен жестко контролироваться, чтобы управление отображением не выходило из-под контроля. Каждый раз, когда вы изменяете предложение, вы должны найти метод, который непосредственно относится к этому предложению и исправить соответствие регулярных выражений.
плюсы и минусы xSpec (контекст/спецификация)
плюсы
- позволяет разработчику постепенно создавать контекст. Контекст может быть настроен для теста, и некоторые утверждения могут быть выполнены против этого контекста. Затем можно указать больше контекста (основываясь на уже существующем контексте), а затем указать больше тестов.
- не сжимать язык. Разработчики могут быть более выразительными о том, как ведет себя определенная часть системы.
- не требуется сопоставление между английским и общим диалектом (потому что его нет).
минусы
- не так доступны для бизнеса. Давайте посмотрим правде в глаза, бизнес не любит распутывать, что они хотят. Если мы дадим им контекстно-ориентированный подход к BDD, то предложение будет просто гласить:"просто заставьте его работать".
- все в коде. Контекстная документация переплетается в коде (поэтому нам не нужно беспокоиться о сопоставлении английского языка с кодом)
- не так читаем, учитывая менее ограничительный глагол.
образцы
на Боулинг Ката очень хороший пример.
SpecFlow Образец
вот как будет выглядеть спецификация в SpecFlow (опять же, это здорово как приемочный тест, потому что он напрямую связывается с бизнесом):
Файл Объектовфайл функций является общим диалектом для теста.
Feature: Score Calculation In order to know my performance As a player I want the system to calculate my total score Scenario: Gutter game Given a new bowling game When all of my balls are landing in the gutter Then my total score should be 0Файл Определения Шага
файл определения шага-это фактическое выполнение теста, этот файл включает сопоставления для SpecFlow
[Binding]
public class BowlingSteps
{
private Game _game;
[Given(@"a new bowling game")]
public void GivenANewBowlingGame()
{
_game = new Game();
}
[When(@"all of my balls are landing in the gutter")]
public void WhenAllOfMyBallsAreLandingInTheGutter()
{
_game.Frames = "00000000000000000000";
}
[Then(@"my total score should be (\d+)")]
public void ThenMyTotalScoreShouldBe(int score)
{
Assert.AreEqual(0, _game.Score);
}
}
образец NSpec, xSpec, Контекст / Спецификация
здесь NSpec пример того же боулинг ката:
class describe_BowlingGame : nspec
{
Game game;
void before_each()
{
game = new Game();
}
void when_all_my_balls_land_in_the_gutter()
{
before = () =>
{
game.Frames = "00000000000000000000";
};
it["should have a score of 0"] = () => game.Score.should_be(0);
}
}
Так Что Да...SpecFlow-это круто, NSpec-это круто
по мере того как вы делаете больше и больше BDD, вы найдете что и флейворы xBehave и xSpec BDD необходимы. xBehave больше подходит для приемочных испытаний, xSpec больше подходит для модульных тестов и доменного дизайна.
Полезные Ссылки
истинный инструмент, управляемый поведением, будет чем-то вроде огурца. Мы используем его на моей работе против кода .NET. Это позволяет нам писать функции, которые определяют поведение системы в целом, а затем мы можем выполнить функции и проверить, что система делает то, что мы ожидаем. Весь процесс работает очень хорошо для нас.
существует реализация .net под названием NStep, которая подключается к cucumber по протоколу wire, что позволяет вам напишите определения шагов в C#, используя lambdas...это довольно круто.
определения шагов выглядят следующим образом:
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 для описания компонентов нижнего уровня? Во-первых, я думаю, что вопрос немного неправильный. Вы не склонны описывать компоненты если эти компоненты непосредственно представляют поведение. Я все равно отвечу на вопрос, в чем, по-моему, суть вопроса.
история ориентированные инструменты, такие как огурец отлично подходят для разговора о поведении с точки зрения клиента / пользователя. Это позволит вам сделать спецификации, которые легко доступны для непрофессионалов. Однако может быть утомительно описывать большие объемы или сложное состояние с помощью этих инструментов.
модульное тестирование, или больше ориентированных на код инструментов спецификации, таких как rSpec и Machine.Спецификация, может быть намного удобнее при работе со сложными или большими государственными настройками. Для управления состоянием можно использовать различные инструменты, доступные для языков. Такие вещи, как наследование и подделки/насмешки. Машина.Спецификация имеет некоторые хорошие подходы для этого для .Чистая единомышленников.
Итак, вы должны использовать огурец, чтобы указать поведение нижнего уровня? Я бы сказал, только если важно иметь высокий уровень видимости для определенного поведения. В моем текущем проекте мы разработали архитектурный компонент для представления определенных интенсивных частей системы бизнес-правил. Эти компоненты указаны с огурцом, но большая часть системы покрыта NUnit.
Btw, SpecFlow действительно хороший и доступный для .NET-людей, просто попадающих в BDD, но в конечном итоге вы захотите перейти на полномасштабный огурец+nStep. Экосистема огурцов огромна и полезна. SpecFlow намного меньше.
кроме того, синтаксис лямбда, предлагаемый nStep, довольно приятнее, чем украшать методы a la SpecFlow или Cuke4Nuke.
Отказ От Ответственности / Фон: Я сделал некоторые из оригинальных разработок на nStep, но я использую SpecFlow в своем текущем проекте. Я работаю в представьте BDD здесь и нужно что-то простое и доступное.
интересно, что этот блог о классификации BDD Tools рассказывает о TDD и ATDD. Как отмечает Лиз Кьоу:BDD - это разговор и исследование. Тем легче для всех вовлеченных парней вносить свой вклад, общаться, делиться идеями, понимать других и т. д. чем быстрее мы получим адекватное решение и лучшее программное обеспечение, которое мы строим. Когда мы, наконец, следовать пути инструмента, каковы инструменты, которые поддерживают сотрудничество между заинтересованными сторонами программных проектов лучший?
на основе этот блог о различиях между TDD, BDD и ATDD Я бы сказал, что есть не менее три разных вкуса BDD:
- Блок Тестирования
JUnit изменил наш взгляд на разработку и тестирование. Одной из его сильных сторон является то, что тесты могут быть написаны на том же языке программирования, что и само приложение. Таким образом, мы можем опираться на знания, мы уже есть в команде доставкой. Когда тесты даже используются для управления развитием, мы достигаем небес TDD.
языки программирования были оптимизированы для уменьшения избыточности, что, по словам Рона Джеффриса, является одним из худших грехов разработчиков. Поэтому, мы часто полагаемся на эти инструменты, когда мы делаем технические испытания, к построить продукт прямо как они помогают нам быть наиболее эффективным.
несколько парней пытались сделать автоматические тесты больше понятно, как модульные тесты на самом деле не читаются. Одной из первых попыток был анализ модульных тестов и предоставление краткого резюме, которое также читается не разработчиками. Например TestDox / AgileDox создает простую документацию из имен методов тестовых классов JUnit или Pickels создает документацию на основе файлов функций, написанных на Корнишоне.
фреймворки, такие как MSpec помогите написать тесты, которые лучше читается и дополнительно обеспечивает читаемый выход. Этот аромат инструментов BDD фокусируется на удобочитаемом выходе, который позволяет привлекать не разработчиков после того, как разработчики сделали свою работу.
- Сценарий Тестирования
до вовлечение заинтересованных сторон в начале цикла разработки, были созданы новые инструменты, которые больше ориентированы на читаемый ввод. огурец использует простые текстовые файлы, чтобы обеспечить человеческие читаемые входные сигналы для автоматизированных тестов. Текстовые файлы содержат сценарии, написанные на специально структурированном языке на основе заданной структуры. Эти рамки являются отличными инструментами, которые поддерживают совместное определение критериев принятия.
- Приемочного Тестирования
параллельно с идеей BDD был разработан еще один аромат инструментов, где FIT был ранним представителем. Это рамки для Интегрированный Тест позволяет указать примеры в таблицах, которые встроены в документацию, связанную с примерами. Для написания этих документов не требуется никаких навыков разработки, и они могут быть легко прочитаны и рассмотрены нетехническими парнями, поскольку они основаны исключительно на тексте. Кроме того, текст может быть структурирован, так как документы не являются обычными текстовыми файлами, а выводятся богатыми редакторами.
FitNesse позволяет задать ожидаемое поведение совместно на основе вики. Поскольку Вики просты в доступе и использовании, они имеют низкую кривую входа и обучения, что способствует общей работе всей команды. Многие сторонники agile подчеркивают, что лучший способ сотрудничества-это общение лицом к лицу. Но если вы запишете то, что вы думали и обсуждали, это должно быть настолько богатым и хорошо структурированным, насколько это возможно.
Concordion обеспечивает много гибкость по мере того как вы можете описать ваши требования в нормальном языке используя абзацы, таблицы и правильная пунктуация. Любая часть описания может использоваться в качестве входных данных для автоматизированных тестов и для проверки результатов тестируемой системы. Поскольку он основан на HTML, вы можете структурировать свои документы и интегрировать изображения. Просто у вас есть выразительность интернета для описания ожидаемого поведения.
BDD должен помочь построить правильный продукт
вы можете реализовать BDD со всеми тремя вариантами инструментов, но каждый из них имеет свой сильные и слабые стороны. Рамки модульного тестирования и xSpec как инструменты прекрасно используют сильные стороны программирования. Как они инструменты от разработчиков для разработчиков, они идеальный выбор если вы пытаетесь получить техническую часть право.
когда вы хотите сообщить о намерении приложения, вам, вероятно, лучше использовать инструмент, который тесно связан с инструментами, которые редакторы используют для своей работы. Если спецификация содержит только входные данные и ожидаемые выходы, любой, кто его читает, должен будет реконструировать ваши идеи из отношения входных данных к ожидаемым результатам. Краткое описание, объясняющее цель спецификации в заголовке, помогает читателю понять структуру спецификации. Документы, основанные на спецификации на примере, могут выглядеть так:
да, SpecFlow круто, NSpec круто ...
FitNesse и Конкордион круты как ну!--8-->