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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

Мне нравится проводить различие между "спецификациями" и "тестами".

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

Если я покрываю метод под названием CalculateSalesTax(decimal amount, State state, Municipality municipality), я все еще собираюсь написать unit test, но я буду называть его спецификацией, потому что я собираюсь изменить его (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 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);
    }
}

Ответ 5

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

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

Ответ 6

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

Cheers, Kris

Ответ 7

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

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