ATDD против BDD и правильное использование каркаса - PullRequest
Новая
       36

ATDD против BDD и правильное использование каркаса

21 голосов
/ 29 июля 2010

Я только начинаю понимать концепцию BDD и слушал разговор Скотта Беллвера с ребятами из Herding Code.Я немного поигрался с SpecFlow и мне это очень нравится.

Я понимаю различие между ATDD и TDD, как описано в сообщении в блоге Классификация инструментов BDD (Unit-Test-Driven vs. Acceptance TestЗа рулем) и немного истории BDD , но это подводит меня к вопросу.

Как описано, разве использование инструмента BDD (такого как MSpec) не является просто еще одной структурой модульного тестирования?Мне кажется, что это так.

Более того, это говорит о том, что использование SpecFlow для спецификации компонентов более низкого уровня (таких как ваши репозитории и службы) было бы неправильным.Если я могу использовать один и тот же инструмент как для ATDD, так и для TDD компонентов более низкого уровня, то почему я не должен?Кажется, здесь все еще есть размытые линии, которые я не совсем понимаю.

Ответы [ 5 ]

29 голосов
/ 11 апреля 2011

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

Один очень важный вопрос, который следует упомянуть, состоит в том, что существует два варианта Behavior Driven Development. Два варианта xBehave и xSpec .

xBehave BDD: SpecFlow

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

xSpec BDD: NSpec

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

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

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

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

Плюсы

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

Против

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

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

Плюсы

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

Против

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

Образцы

Bowling Kata является довольно хорошим примером.

Образец 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, Context / Specification

Вот 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, вы будетеобнаружите, что необходимы и BBD, и xBehave, и xSpec.xBehave больше подходит для приемочных тестов, xSpec больше подходит для модульных тестов и проектирования на основе доменов.

Соответствующие ссылки

11 голосов
/ 29 июля 2010

Настоящим инструментом, управляемым поведением, будет что-то вроде огурца.Мы используем его на моей работе против кода .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

2 голосов
/ 02 августа 2010

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

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

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

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

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

Кстати, SpecFlow действительно хорош и доступен для пользователей .NET, только начинающих BDD, но в конечном итоге вы захотите перейти к полноценному Cucumber + nStep. Огуречная экосистема огромна и полезна. SpecFlow гораздо меньше.

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

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

2 голосов
/ 29 июля 2010

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

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

0 голосов
/ 23 октября 2014

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

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

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

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

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

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

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

Рамки тестирования сценариев

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

Основы приемочного тестирования

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

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

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

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

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

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

enter image description here enter image description here

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

FitNesse и Concordion тоже крутые

...