Мы использовали BDD - Behavior Driven Development (с точки зрения Dan North) в качестве механизма регистрации пользовательских приемочных тестов и разработки дисков на пара проектов с достойным успехом. На сегодняшний день, хотя мы фактически не автоматизировали сами тесты.
Теперь я ищу автоматизацию тестов, но я не уверен, какая структура поведения вернется. До сих пор NBehave кажется предвестником, но есть ли другие, над которыми я должен смотреть? Есть ли явный "победитель" на данный момент?
Одна важная точка зрения заключается в том, что существуют два варианта разработки, управляемой поведением.. Два варианта: xBehave и xSpec.
SpecFlow (очень похож на огурец из стека Ruby) отлично подходит для облегчения тестов xBehave BDD в качестве критериев приемки. Однако он не обеспечивает хороший способ написания поведенческих тестов на уровне единицы. Есть еще несколько инфраструктур тестирования xBehave, но SpecFlow получил большую тягу.
Объективно. Учитывая доступные спецификации контекстных спецификаций, MSpec был самым длинным и является наиболее широко используемой средой контекста/спецификации в сообществе .Net.
Я лично рекомендовал бы NSpec (вдохновленный непосредственно RSpec для Ruby). Полное раскрытие информации, я являюсь одним из авторов NSpec. Вы можете выполнить BDD, просто используя NUnit или MSTest... но они кажутся короткими (очень сложно создавать контексты постепенно). MSpec также является опцией и является самой зрелой структурой контекста/спецификации для .Net. Но в NSpec есть несколько вещей, которые проще.
Два варианта BDD в основном существуют из-за ортогональных преимуществ, которые они предоставляют.
Bowling Kata - довольно хороший пример.
Вот что спецификация будет выглядеть в 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);
}
}
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 одного и того же бота-ката:
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, вы обнаружите, что необходимы как xBehave, так и xSpec-ароматы BDD. xBehave больше подходит для тестов Acceptance, xSpec больше подходит для модульных тестов и разработки, ориентированных на домен.
Объективные показатели, такие как возраст и стабильность, должны быть фактором, и я хотел бы призвать всех учитывать это. Но, пожалуйста, также принять во внимание, что более новые рамки могут обеспечить более сжатое api, лучшее использование языковых конструкций и основываться на уроках, извлеченных для прошлых фреймворков. MSpec предоставляет конструкторы Given, Because, It и Cleanup.. но они стоят дорого: статическая инициализация для всех участников, взлом класса и синтаксически жесткая из-за его уникального использования делегатов. Вы обнаружите, что простейшие тесты MSpec проще в NSpec. Вот более сложный набор тестов, написанный как в MSpec, так и в NSpec.
A Сравнение xUnit, MSpec и NSpec: https://gist.github.com/amirrajan/6701522
Отъезд SpecFlow.
Это инструмент, вдохновленный Cucumber, который нацелен на обеспечение прагматичного и без трения подхода к разработке, основанному на приемочных испытаниях, и разработке поведенческих разработок для .NET проектов сегодня.
Интеграция VisualStudio кажется особенно перспективной.
StoryQ выглядит неплохой альтернативой NBehave с его свободным интерфейсом. Я определенно проверил бы это.
Я не думаю, что есть "победитель". Другие рамки включают 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.
Там также Specter, который определяет DSL в Boo, чтобы сделать его более естественным.
Я бы вообще пошел на пользу NBehave, в сочетании с MbUnit и независимо от того, какие DI/mocking frameworks вам нужны. Это справедливый комментарий Джима Бургера о том, что NBehave очень многословный, и я иногда использую cut-and-paste. Тем не менее, он отлично работает - я использую плагин 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. Наличие встроенной интеграции в визуальную студию с R # является ключевой особенностью для нас.
Поскольку наш дизайн - это все MVC3, мы также будем применять шаблон разделения для наших MVC-контроллеров. Это позволит нам писать спецификации непосредственно против оркестра. Затем мы можем писать истории непосредственно против использования нашего приложения.
Также проверьте 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
Поскольку я сейчас имею дело с BDD для системных тестов для критически важных приложений безопасности, я могу поделиться своим опытом, что вы не должны недооценивать силу "тестов, написанных на естественном языке" вместо "кода".
Мы всегда стремились предложить язык функций, который любой может понять без какого-либо технического опыта или опыта в программировании (см. пример выше), и мы хорошо это сделали. Помимо того факта, что я никогда никому не объяснял синтаксис, каждый сразу понял смысл теста, разработчика, менеджера и даже тестера.
Я бы ни в коем случае не избегал теста, написанного на языке программирования, таком как примеры MSpec выше. Если я появлюсь с таким испытанием в офисе менеджера, он вышвырнет меня. Но он заинтересован в чтении тестов на основе Gherkin-Syntax. Чем больше ребят смогут читать и модифицировать тесты, тем лучше.
И последнее, но не менее важное: эти тесты переносимы на любой другой язык программирования, любую другую платформу, любой другой инструмент автоматизации тестирования без каких-либо изменений.
Опять же, ответ еще раз:
Не заботьтесь об инструменте и его функциях, выберите инструмент, который позволяет вам легко переключаться на другой инструмент в любое время без потери информации. Инструменты приходят и уходят, мои тесты должны длиться дольше.: -)
Я могу порекомендовать использовать SpecFlow. У вас есть полный доступ к полной библиотеке .Net и всем ее функциям, ваши тесты остаются переносимыми. Это может дать вам преимущество перед совершенно портативными решениями, такими как Robot Framework, если вы не против переносимости. Тем не менее, вы всегда можете улучшить стабильность и мобильность системы, используя различные инструменты для разработки и тестирования. Поэтому тестирование программного обеспечения .Net с использованием подхода BDD на основе python может быть хорошей (или даже лучшей) идеей в некоторых случаях.
Тем не менее, SpecFlow показал, что он стабилен и пуленепробиваемо в каждодневном тестировании, включая тесты на ночную сборку и т.д. в проектах среднего размера. Кроме того, он хорошо интегрируется в среду Microsoft Unit Test.