Какой самый зрелый BDD-фреймворк для .NET?[закрыто]

StackOverflow https://stackoverflow.com/questions/307895

  •  08-07-2019
  •  | 
  •  

Вопрос

Мы использовали BDD - Разработка, ориентированная на поведение (с точки зрения Дэна Норта) как механизм записи пользовательских приемочных тестов и стимулирования разработки пары проектов с приличным успехом.Однако на сегодняшний день мы фактически не автоматизировали сами тесты.

Сейчас я занимаюсь автоматизацией тестов, но я не уверен, какую поведенческую структуру использовать.Пока NBehave кажется предшественником - но есть ли какие-то другие, на которые мне следует обратить внимание?Есть ли явный "победитель" на данный момент?

Это было полезно?

Решение

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

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

xBehave БДД:Специальный поток

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

xSpec BDD:MSpec

Объективно говоря.Учитывая доступные фреймворки спецификаций контекста, MSpec существует дольше всех и является наиболее широко используемой фреймворком контекста / спецификации в сообществе .Net.

Другой фреймворк xSpec BDD:NSpec

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

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

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

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

Плюсы

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

Минусы

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

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

Плюсы

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

Минусы

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

Образцы

Тот Самый Боулинг - Ката это довольно хороший пример.

Образец специального потока

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

Scenario: Single Pin
  Given a new bowling game
  When I've hit exactly 1 pin
  Then my total score should be 1
Файл Определения шага

Файл определения шага - это фактическое выполнение теста, этот файл включает сопоставления для 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";
    }

    [When(@"I've hit exactly 1 pin")]
    public void When1PinIsHit()
    {
        _game.Frames = "10000000000000000000";
    }

    [Then(@"my total score should be (\d+)")]
    public void ThenMyTotalScoreShouldBe(int score)
    {
        Assert.AreEqual(score, _game.Score);
    }
}

Образец MSpec, xSpec, Контекст / Спецификация


public class describe_BowlingKata
{
    public static Game game;

    public class when_all_balls_land_in_the_gutter : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "00000000000000000000";

        It should_have_a_score_of_0 = () => game.Score.ShouldBe(0);
    }

    public class when_a_single_pin_is_hit : describe_BowlingKata
    {
        Establish ctx = () => game = new Game();

        Because of = () => game.Frames = "10000000000000000000";

        It should_have_a_score_of_1 = () => game.Score.ShouldBe(1);
    }
}

Образец 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);
    }

    void when_a_single_pin_is_it()
    { 
        before = () => game.Frames = "10000000000000000000";

        it["should have a score of 1"] = () => game.Score.should_be(1);
    }
}

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

MSpec против NSpec

Объективные показатели, такие как возраст и стабильность, должны быть важным фактором, и я бы призвал всех принять это во внимание.Но, пожалуйста, также примите во внимание, что новые фреймворки могут предоставлять более краткий api, лучше использовать языковые конструкции и опираться на уроки, извлеченные из прошлых фреймворков.MSpec предоставляет конструкции Given, Because, It и Cleanup .. но за них приходится платить:статическая инициализация для всех членов, взрыв класса, и она синтаксически жесткая из-за уникального использования делегатов.Вы обнаружите, что простейшие тесты MSpec проще в NSpec.Вот более сложный набор тестов, написанный как на MSpec, так и на NSpec.

Сравнение xUnit, MSpec и NSpec: https://gist.github.com/amirrajan/6701522

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

RSpec против огурца (истории RSpec)

BDD с Cucumber и rspec - когда это излишне?

Другие советы

Ознакомьтесь с SpecFlow .

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

Интеграция VisualStudio выглядит особенно многообещающе.

StoryQ выглядит как хорошая альтернатива NBehave с его интерфейсом Fluent. Я определенно проверил бы это.

Я не думаю, что на самом деле есть «победитель». Другие платформы включают в себя SpecUnit.NET проект и MSpec также демонстрирует перспективу с Начало работы адаптера Gallio . Технически, так как IronRuby уже на горизонте, rSpec может быть вариантом для тех, кто готов идти в тупик. NBehave + NSpec может быть самой старой платформой с наилучшей автоматизацией, хотя я столкнулся с чрезмерно многословным синтаксисом.

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

Я лично рекомендовал бы BDDfy , что, на мой взгляд, прекрасно! Он с открытым исходным кодом, поддерживает условные и свободно основанные описание сценария, охватывает как приемочные, так и модульные тесты. Вы можете найти его на GitHub .

Robot Framework также можно использовать с IronPython для выполнения ATDD или BDD в .Net. Я думаю, что возможности выражения Robot Framework лучше, чем, например. SpecFlow или NSpec . Это не заставляет вас использовать определенный синтаксис, но вместо этого использует подход, основанный на ключевых словах. Если вы тестируете веб-приложения, у него есть Selenium2Library , который обеспечивает привязки к Selenium WebDriver.

Существует также Spectre , который определяет DSL в Boo, чтобы сделать его более естественным.

Как правило, я бы предпочел NBehave в сочетании с MbUnit и любыми платформами ввода / вывода, которые вам нужны. Это справедливый комментарий Джима Бургера, что NBehave очень многословен, и я иногда использую вырезать и вставлять. Тем не менее, он прекрасно работает - я использую плагин Gallio ReSharper, поэтому я просто показываю дополнительное окно. Тем не менее, еще не пробовал с ccnet.

Проверьте этот пост в блоге и его комментарии на предмет вдохновляющих идей: http : //haacked.com/archive/2008/08/23/introducing-subspec.aspx/

Concordion.NET поддерживает не только BDD, но и ATDD: http://assertselenium.com/2012/11/05/difference-between-tdd -bdd-ATDD / Технические характеристики написаны на простом английском языке используя HTML. ИМХО это одно из преимуществ Concordion.NET. Документы HTML могут быть организованы в виде навигации, чтобы создать систему живой документации . А поскольку тесты выполняются на системе, вы можете быть уверены, что документация всегда актуальна.

Я начинаю свой первый выход в BDD с небольшого заявления с моей командой. Инструменты, которые мы выбираем для выполнения этой работы: Specflow с Selenium Webdriver для xBehave истории и MSpec с Machine.Fakes.Moq для контейнера для автоматической блокировки для наших модульных тестов xSpec. Благодаря тому, что Resharper является и нашим историком, и специалистом по спецификации, благодаря интеграции, поддерживаемой Specflow и MSpec. Нативная интеграция в Visual Studio с R # является для нас ключевой особенностью.

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

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

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

Я бы в любом случае избегал теста, написанного на языке программирования, как в приведенных выше примерах MSpec. Если я появлюсь с таким тестом в офисе менеджера, он меня выгонит. Но он заинтересован в чтении тестов на основе синтаксиса Gherkin. Чем больше ребят смогут читать и изменять тесты, тем лучше.

И последнее, но не менее важное: эти тесты переносимы на любой другой язык программирования, любую другую платформу, любой другой инструмент автоматизации тестирования без каких-либо изменений.

Опять же, ответ еще раз:

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

Я могу рекомендовать использовать SpecFlow. У вас есть полный доступ ко всей библиотеке .Net и ко всем ее функциям, ваши тесты остаются переносимыми. Это может дать вам преимущество перед полностью портативными решениями, такими как Robot Framework, если вы не против переносимости. Однако вы всегда можете улучшить стабильность и переносимость системы, используя различные инструменты для разработки и тестирования. Поэтому тестирование программного обеспечения .Net с подходом BDD на основе Python может быть хорошей (или даже лучшей) идеей в некоторых случаях.

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

Также проверьте UBADDAS, специфичный для UAT, найденный в

https://github.com/KernowCode/UBADDAS

с объяснением здесь

http://kernowcode.wordpress.com/ (в июне 2014 года)

Вы можете написать такой тест 

[Test]
public void IWantToRegisterANewUser()
{
  var user = new User();
  ICustomer customer = new Customer();

  SoThat(MyBusinessValue.IncreaseCustomerBase)
    .As(user)
    .Given(customer.Register)
    .When(customer.Confirm_Registration)
    .Then(customer.Login);
}

и производит это 

I want to register a new user
  so that Increase customer base
       as user
    given Register customer
     when Confirm customer registration
     then Login customer
Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top