Ответ 1

Быстрый ответ

Одна важная точка зрения заключается в том, что существуют два варианта разработки, управляемой поведением.. Два варианта: xBehave и xSpec.

xBehave BDD: SpecFlow

SpecFlow (очень похож на огурец из стека Ruby) отлично подходит для облегчения тестов xBehave BDD в качестве критериев приемки. Однако он не обеспечивает хороший способ написания поведенческих тестов на уровне единицы. Есть еще несколько инфраструктур тестирования xBehave, но SpecFlow получил большую тягу.

xSpec BDD: NSpec

Для разработки с учетом поведения на уровне единицы, я бы рекомендовал NSpec (вдохновленный непосредственно RSpec для Ruby). Вы можете выполнить BDD на уровне единицы, просто используя NUnit или MSTest... но они кажутся короткими (очень сложно наращивать контексты постепенно). MSpec также является опцией, в нем много работы, но есть только что-то, что просто simpilier в NSpec (вы можете постепенно наращивать контекст в MSpec, но для этого требуется наследование, которое может стать сложным).

Длительный ответ

Два варианта BDD в основном существуют из-за ортогональных преимуществ, которые они предоставляют.

Плюсы и минусы xBehave (синтаксис GWT)

Pros

• помогает облегчить разговоры с бизнесом через общий диалект (например, данный...., и учитывая...., когда......, а когда....., тогда...., And Then)
• общий диалект может быть затем сопоставлен с исполняемым кодом, который доказывает бизнесу, что вы на самом деле закончили то, что, как вы сказали, закончили.
• диалект сжимается, поэтому бизнес должен устранить требования и вписаться в предложения.

Против

• В то время как подход xBehave хорош для управления критериями приемлемости высокого уровня, циклы, необходимые для сопоставления английского языка с исполняемым кодом через атрибуты, делают невозможным вытеснение домена на уровне единицы.
• Отображение общего диалекта в тестах PAINFUL (увеличение вашего регулярного выражения). Каждое предложение, созданное бизнесом, должно быть сопоставлено с исполняемым методом через атрибуты.
• Общий диалект должен быть жестко контролирован, так что управление отображением не выходит из-под контроля. Каждый раз, когда вы меняете предложение, вы должны найти метод, который непосредственно относится к этому предложению, и исправить соответствие регулярных выражений.

Плюсы и минусы xSpec (Контекст/Спецификация)

Pros

• Позволяет разработчику постепенно наращивать контекст. Контекст может быть настроен для теста, и некоторые утверждения могут быть выполнены в этом контексте. Затем вы можете указать больше контекста (исходя из контекста, который уже существует), а затем указать больше тестов.
• Отсутствует сжимающий язык. Разработчики могут быть более выразительными в отношении того, как ведет себя определенная часть системы.
• Не требуется сопоставление между английским и общим диалектом (потому что его нет).

Против

• Не подходит для бизнеса. Давайте посмотрим правде в глаза, бизнес не любит, чтобы устранить то, что они хотят. Если бы мы предоставили им подход, основанный на контекстах к BDD, тогда предложение просто прочитало бы "Просто сделайте это".
• Все в коде. Контекстная документация переплетается внутри кода (поэтому нам не нужно беспокоиться о привязке английского к коду)
• Не так читается, учитывая менее строгие формулировки.

Примеры

Bowling Kata - довольно хороший пример.

SampleFlow Sample

Вот что спецификация будет выглядеть в 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);
    }
}

Итак, Yea... SpecFlow классный, NSpec классный

Как вы все больше и больше BDD, вы обнаружите, что необходимы как xBehave, так и xSpec-ароматы BDD. xBehave больше подходит для тестов Acceptance, xSpec больше подходит для модульных тестов и разработки, ориентированных на домен.

Релевантные ссылки

• RSpec vs Cucumber (рассказы RSpec)
• BDD с Cucumber и rspec - когда это избыточное?
• сайт NSpec Project
• Непрерывное тестирование
• Введение в BDD и Mocking
• BDD с использованием NUnit и Moq

Ответ 2

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

http://cukes.info/

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

Определения шагов выглядят следующим образом:

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

Ответ 3

Я думаю, ваше понимание согласуется с моим. 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.

Нет причин не размещать unit test ваши репозитории на более узком уровне. Я думаю, что оба они полезны и уместны.

Ответ 4

Не могу ли я использовать обычные инструменты для тестирования единиц? BDD - это процесс и менталитет, и поэтому да, вы можете сделать это с помощью любых инструментов (или нет, вы можете написать свой собственный без инструмента, если хотите). Однако инструменты TDD имели определенные предположения, которые вызывают некоторое трение при попытке сделать что-то в BDD-способе. Например, TDD предполагает, что вы тестируете архитектурную единицу программного обеспечения; класс, модуль, сервис. В то время как BDD предполагает, что вы указываете какую-то функциональную часть системы.

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

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

Тестирование единиц измерения или другие инструменты, ориентированные на код, такие как rSpec и Machine.Specification, могут быть намного более удобными при работе со сложными или большими настройками состояния. Вы можете использовать различные инструменты, доступные для языков для управления состоянием. Такие вещи, как наследование и подделки/издевки. У Machine.Specification есть некоторые хорошие подходы к этому для .NET.

Итак, следует ли использовать огурец для определения поведения более низкого уровня? Я бы сказал, только если важно иметь высокий уровень видимости для этого конкретного поведения. В моем текущем проекте мы разработали архитектурный компонент для представления определенных бизнес-правил, интенсивные части системы. Эти компоненты указаны с помощью огурца, но большая часть системы покрыта NUnit.

Btw, SpecFlow действительно приятный и доступный для людей .NET, которые просто попадают в BDD, но в конце концов вы захотите окончить полномасштабный Cucumber + nStep. Огуречная экосистема ОГРОМНАЯ и полезная. SpecFlow намного меньше.

Кроме того, синтаксис лямбда, предлагаемый nStep, довольно приятен, чем необходимость декорировать методы a la SpecFlow или Cuke4Nuke.

Отказ от ответственности/Общие сведения: Я сделал некоторые из первоначальных разработок на nStep, но я использую SpecFlow для моего текущего проекта. Я работаю над внедрением BDD здесь и нуждаюсь в чем-то простом и доступном.

Ответ 5

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

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

• Модули тестирования модулей

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

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

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

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

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

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

3. Приемочные испытания

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

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

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

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

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

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

Да, SpecFlow классный, NSpec классный...

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