В чем разница между написанием тестовых примеров для BDD и TDD? [Дубликат]

Разница между BDD и TDD заключается в том, что BDD начинается с B, а TDD начинается с T. Но если серьезно, то получение с TDD заключается в том, что слишком много разработчиков сосредоточились на «How» при написании своих модульных тестов, поэтому они закончились с очень хрупкими тестами, которые не более чем подтверждают, что система делает то, что она делает.

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

Разработка, управляемая поведением, является расширением /пересмотром Test Driven Development. Его цель - помочь разработчикам системы (например, разработчикам) определить подходящие тесты для написания, т. Е. Тесты, которые отражают поведение, желаемое заинтересованными сторонами. Эффект заканчивается тем же самым - разработать тест, а затем разработать код /​​систему, которая проходит тест. Надежда в BDD заключается в том, что тесты действительно полезны, показывая, что система удовлетворяет требованиям.

UPDATE

Единицы кода (отдельные методы) могут быть слишком гранулированными, чтобы представлять поведение, представленное поведенческими тестами, но вы все равно должны тестировать их с помощью модульных тестов, чтобы гарантировать их правильную работу. Если это то, что вы имеете в виду под тестами «TDD», то да, вы все еще нуждаетесь в них.

BDD использует нечто, называемое «Ubiquitous Language», совокупность знаний, которые могут быть поняты как разработчиком, так и клиентом. Этот вездесущий язык используется для формирования и разработки требований и тестирования, необходимых на уровне понимания клиента.

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

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

Проблема, с которой многие сталкиваются, заключается в том, что TDD предназначен для разработчиков, а не для тестеров. Совершено правильно TDD не является в первую очередь стратегией тестирования или приемочным тестом, но является методом, который обеспечивает хороший дизайн программного обеспечения с нуля - небольшие, свободно связанные классы, четкие, четко определенные интерфейсы и постоянно очищаемый код через постоянный рефакторинг. Рефакторинг, который выполняется регулярно, часто и с уверенностью.

В результате вы получите исчерпывающий набор тестов, который может сформировать part вашего процесса CI /build - это бонус, а не цель.

BDD приветствует это, перекрывая разрыв между бизнес-требованиями и приемочными испытаниями более высокого уровня. Это удовлетворение BDD-пакета, которое охватывает процесс разработки и определяет, когда продукт в целом был надлежащим образом доставлен.

Различия между TDD и BDD незначительны и в основном сводятся к языку . тесты BDD часто записываются в следующей форме:

public void shouldBuyBread () throws Exception {
   //данный
   given (seller.askForBread ()). willReturn (новый Хлеб ());

   //когда
   Товары товаров = shop.buyBread ();

   //тогда
   assertThat (товары, содержатBread ());
 }

Если вы создаете тест с точки зрения поведения , он помогает охватить ответственность класса и ведет к лучшему дизайну (по крайней мере, согласно BDD'sers). BDD иногда фокусируется на исполняемых спецификациях , которые могут понять ваши эксперты /клиенты вашего домена.

BDD также больше связан с тем, что Мартин Фаулер называет «внешними» или «макетирующими» тестами , в отличие от для проверки состояния.

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

• Разработка, управляемая поведением - это подмножество Test Driven Development
• TDD фокусируется на каждом модульном тесте для каждой функции, не имеет значения, что он делает. BDD фокусируется на программном обеспечении, которое имеет значение
• <Сильный> Idiom . TDD подходит для тестов, BDD обеспечивает рассказ истории

Примеры JavaScript

Модульные тесты в жасмине (BDD)

описать («Набор», function () {
  он ("содержит spec с ожиданием", function () {
    ожидать (правда) .toBe (истина);
  });
});

Модульные тесты в jsUnity (TDD)

function test_lists () {assert.areEqual ([1, 2, 3], [1, 2, 3])}

Вот несколько библиотек Python , которые помогают создавать больше BDD как тесты с помощью рамок unittest:

• Салат-латук : огурец для питона
• Hamcrest

BDD добавляет еще один уровень абстракции к тестам. Код более высокого уровня (обычно в txt) описывает то, что тестирует система, код нижнего уровня описывает, как он его тестирует. Таким образом, среда BDD может использовать структуру TDD в коде нижнего уровня.

Это помогает много, оставаясь СУХОЙ. По TDD вы можете легко завершить «мокрые» тесты, содержащие много дубликатов кода, которые облегчают их перерывы путем рефакторинга кода и тестов с ним. BDD вам нужно изменить только уровень меньшей абстракции путем рефакторинга кода, поэтому, если спецификация не изменится, код более высокого уровня не изменится.

Btw. это простой «Чистый код», обычно этого достаточно, чтобы прочитать материал с высоким уровнем абстракции, чтобы понять, что он делает, и копать глубже код тестирования уровня абстракции только в том случае, если вам это действительно нужно. Это делает (тест) код более понятным в целом.

Неверный пример (потому что он слишком прост):

стиль жасмина TDD

calculator.add.specs

описать («Калькулятор: добавить», function () {

    он («должен иметь возможность добавить 2 числа вместе», function () {
        var total = add (1, 2);
        ожидать (всего) .toBe (3);
    });

    он («должен иметь возможность добавить 3 числа вместе», function () {
        var total = add (1, 2, 3);
        ожидать (всего) .toBe (6);
    });
});

стиль BDD с жасмином-огурцом

calculator.specs

(«Калькулятор: добавить»)
    .scenario ('должен быть в состоянии добавить 2 числа вместе')
        .when («Я вхожу в« 1 »)
        .and ('Я добавляю "2")
        . then («Я должен получить« 3 »)
    .scenario ('должен иметь возможность добавить 3 числа вместе')
        .when («Я вхожу в« 1 »)
        .and ('Я добавляю "2")
        .and ('Я добавляю "3")
        . then («Я должен получить« 6 »)

calculator.steps

featureSteps ( 'Калькулятор:')
    .before (функция () {
        this.values ​​= [];
        this.total = null;
    })
    .when ('I enter "(. *)"', function (value) {
        this.values.push (Число (значение));
    })
    .when ('I add "(. *)"', function (value) {
        this.values.push (Число (значение));
    })
    . then («Я должен получить» (. *) «', function (expectedTotal) {
        this.total = add.apply (null, this.values);
        ожидать (this.total) .toBe (Number (expectedTotal));
    });

реализация

calculator.js

function add () {
    var args = Array.prototype.slice.call (аргументы);
    var total = 0;
    для (var i в args)
        total + = args [i];
    общая сумма возврата;
}

Теперь, если я переименую функцию add () в sum (), мне нужно изменить код TDD в 2 местах, а код BDD - только в одном месте в файле шагов . Ofc. добавление еще одного уровня абстракции требует большего количества кода ...

Просто чтобы это запуталось, поймите, что многие люди теперь ассоциируют BDD с огурцом. Они рассматривают любые тесты, которые вы пишете, используя синтаксис, полученный из gherkin, для проверки BDD, и все, что написано с использованием модульной тестовой среды (junit, unittest.py и т. Д.), Должно быть TDD.

Это неправильно. В этом случае среда не определяет сообщение. Также не используется издевательство (ИМХО).

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

Спецификации BDD часто записываются на языке, подобном огрунке, если людям, которые должны указать эту функцию, не все код чтения /записи (частый случай в крупных организациях или где настоящий клиент является частью команды). В противном случае, gherkin-ese не требуется. Они, как правило, являются результатом знаменитой встречи 3 Amigos: бизнес, тест, dev, все это делают вместе. При использовании BDD-фреймворка (подгонка, огурец и т. Д.) Тест медленнее и требует немного больше инфраструктуры, поэтому мы сохраняем их относительно редкими - несколько за историю.

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

Если вы используете BDD на внешнем слое, все же полезно делать TDD во внутреннем цикле из-за рефакторинга и способности обнаруживать ошибки и избегать ошибок быстрее.

Не является доказательством правильности для большой системы. Не заменяет ручку и перфорирование. Не обеспечивает безопасность потока. Тесты - это помощь в разработке, а не гарантии идеальной проверки ошибок.