Испытаны ли приемочные испытания BDD?

Question

Или, если у вас есть тесты BDD, вам нужно что-то вроде Fitnesse?

Answer 1

BDD «тесты» существует на нескольких различных уровнях детализации, вплоть до первоначального видения проекта. Большинство людей знают о сценариях. Несколько человек помнят, что BDD started off with the word "should" в качестве замены для теста JUnit - в качестве замены TDD. Причина, по которой я ставил «тесты» в кавычках, состоит в том, что BDD не совсем о тестировании; он сосредоточен на поиске мест, где есть недостаток или несоответствие понимания.

Из-за этого внимания разговоры гораздо важнее, чем инструменты BDD.

Я собираюсь сказать это снова.Разговоры гораздо важнее, чем инструменты BDD.

Приемочные испытания на самом деле не гарантируют разговоры, и обычно они исходят из предположения, что тесты, которые вы пишете, являются правильными тестами. В BDD мы предполагаем, что мы не знаем, что делаем (и, вероятно, не знаем, что мы не знаем). Вот почему мы используем такие вещи, как «Given, When, Then» - чтобы мы могли вести беседы вокруг сценариев и/или примеров на уровне единицы. (Эти два уровня, с которыми знакомы большинство людей - эквивалент приемочных испытаний и модульных тестов, - но они поднимаются по шкале).

Мы не называем их «приемочные испытания», потому что вы не можете попросить делового человека «Пожалуйста, помогите мне с моим приемочным тестом». Они будут смотреть на вас с очень странным, прищуренным взглядом, а затем уволят вас, как , что девушка geek. 93% из вас этого не хотят.

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

И вы ошиблись. Really, honestly, you are. Даже если вы думаете, что это не так, это только потому, что вы не понимаете невежество второго порядка. Вы не знаете, что не знаете, и все в порядке, если вы нашли те места, где вы, , могли знать, что вы не знаете. (Вы не найдете их всех. Не позволяйте парадоксальности категоризации держать вас в ночное время.)

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

Еще раз. Разговоры гораздо важнее, чем инструменты BDD.

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

Сказав, что если вы должны, начните с инструмента, положите Slim за Fitnesse, чтобы он мог работать прекрасным. Представление/When/Thens без необходимости возиться со столами и креплениями Fit. GivWenZen основан на Slim и любой из них камней. FitSharp эквивалентен тем из вас в пространстве .NET. Или просто используйте Cucumber или SpecFlow, или knock up a little custom DSL*, которые будут выполнять эту работу в течение многих лет.

Прозрачность: * Я написал это. И бит JBehave. Хотелось бы, чтобы мы назвали его «Dont-concent-on-BDD-tools-Behave». Я мог бы сильно участвовать в других бит BDD.Плюс Дэн Север купит мне пинту, если я смогу получить это сообщение, так что это не совсем беспристрастный совет.

Независимо от того, у вас есть разговоры. Это просто люди. Поговорите.

Answer 2

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

Когда вы слышите о «BDD-фреймворках», динамик обычно означает фреймворк для записи всех ваших обычных видов тестов, но с завихрением BDD. Например, в RSpec вы все еще записываете модульные тесты; вы просто добавляете к ним BDD-аромат.

Answer 3

Хотя BDD больше, чем объем просто тестов, действительно существуют тесты BDD. Эти тесты являются Unit Tests, которые следуют за языком BDD.

При возникновении некоторого начального контекста (givens), Когда происходит событие, затем обеспечит некоторые результаты.

Есть несколько хороших фреймворков BDD, доступных в зависимости от вашего предпочтительного языка. JBehave для Java RSpec Руби NBehave для .NET

Answer 4

Я хотел бы провести различие между «стопами» и «тесты.»

Если я использую метод GetAverage(IEnumerable<int> numbers), я собираюсь написать более или менее стандартный модульный тест.

Если я использую метод CalculateSalesTax(decimal amount, State state, Municipality municipality), я все еще собираюсь написать модульный тест, но я назову его спецификацией, потому что я собираюсь изменить его (1), чтобы проверить поведение подпрограммы , и (2), поскольку сам тест будет документировать как процедуру, так и критерии ее принятия.

Рассмотрим:

[TestFixture] 
public class When_told_to_calculate_sales_tax_for_a_given_state_and_municipality() // the name defines the context 
{ 
    // set up mocks and expected behaviour 
    StateSalesTaxWebService stateService 
     = the_dependency<IStateSalesTaxWebService>; 
    MunicipalSurchargesWebService municipalService 
     = the_dependency<IMunicipalSurchargesWebService>; 

    stateService.Stub(x => x.GetTaxRate(State.Florida)) 
     .Return(0.6); 
    municipalService.Stub(x => x.GetSurchargeRate(Municipality.OrangeCounty)) 
     .Return(0.05); 

    // run what's being tested 
    decimal result = new SalesTaxCalculator().CalculateSalesTax 
     (10m, State.Florida, Municipality.OrangeCounty); 

    // verify the expected behaviour (these are the specifications) 
    [Test] 
    public void should_check_the_state_sales_tax_rate() 
    { 
     stateService.was_told_to(x => x.GetTaxRate(State.Florida)); // extension methods wrap assertions 
    } 

    [Test] 
    public void should_check_the_municipal_surcharge_rate() 
    { 
     municipalService.was_told_to(x => x.GetSurchargeRate(Municipality.OrangeCounty)); 
    } 

    [Test] 
    public void should_return_the_correct_sales_tax_amount() 
    { 
     result.should_be_equal_to(10.65m); 
    } 
} 

Answer 5

JBehave (и NBehave недавно добавили такую ​​же поддержку) работать с регулярными тестовыми файлами, так что в то время как многие другие структуры добавить «BDD вкуса tounit испытание» спецификация поведения текста на основе/примеры, созданное с помощью JBehave подходят для приемочных испытаний. И нет, для этого вам не нужна пригодность.

Чтобы понять, как это работает, я предлагаю JBehaves 2min tutorial.

Answer 6

Для тестирования BDD в Flex вы можете попробовать GivWenZen-flex проверить это http://bitbucket.org/loomis/givwenzen-flex.

Приветствия, Kris

Answer 7

Проведенные хорошо протестированные тесты xBehavior BDD являются критериями приемлемости пользователя, управляемыми роботами.

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