Являются ли BDD тесты приемочными?

Question

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

Answer 1

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

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

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

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

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

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

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

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

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

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

Сказав, что, если вы должны начать с инструмента, поставьте Slim за Fitnesse, чтобы он мог прекрасно работать с заданным моментом, когда не нужно возиться со столами и приборами Fit. GivWenZen основан на Слиме, и любой из них качается. FitSharp - это эквивалент для тех, кто работает в .NET. Или просто используйте Cucumber, или SpecFlow, или , подберите небольшой пользовательский DSL *, который будет хорошо работать в течение многих лет.

Прозрачность: * Я написал это. И кусочки JBehave. Хотелось бы, чтобы мы назвали это "Не концентрируйся на BDD-tools-Behave". Я мог бы быть сильно вовлечен в другие биты BDD. Кроме того, Дэн Норт купит мне пинту, если я смогу передать это сообщение, так что это не совсем беспристрастный совет.

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

Answer 2

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

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

Answer 3

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

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

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

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

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

Существует несколько хороших BDD-сред, доступных в зависимости от вашего предпочтительного языка. JBehave для Java RSpec для Ruby NBehave для .NET

Answer 6

Испытания xBehavior BDD, реализованные надлежащим образом, являются критериями приемлемости для роботов.

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

Answer 7

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

Ура, Kris