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

    

У этого вопроса уже есть ответ:

    
  •              Связь между BDD и TDD                                      3 ответов                          
  •     

Я изучаю запись тестовых примеров для BDD (Behavior Driven Development) с использованием specflow. Если я пишу всесторонние тесты с BDD, нужно ли отдельно тестировать тест TDD (Test Driven Development)? Нужно ли писать тестовые примеры как для TDD, так и для BDD отдельно, или они фактически одинаковы?

Мне кажется, что оба они одинаковы, с той лишь разницей, что тесты BDD могут быть поняты не разработчиками и тестерами.

243 голоса | спросил arjun 15 FebruaryEurope/MoscowbWed, 15 Feb 2012 20:59:04 +0400000000pmWed, 15 Feb 2012 20:59:04 +040012 2012, 20:59:04

8 ответов


211

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

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

ответил Michael Brown 15 FebruaryEurope/MoscowbWed, 15 Feb 2012 23:06:18 +0400000000pmWed, 15 Feb 2012 23:06:18 +040012 2012, 23:06:18
51

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

UPDATE

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

ответил Matthew Flynn 15 FebruaryEurope/MoscowbWed, 15 Feb 2012 21:09:46 +0400000000pmWed, 15 Feb 2012 21:09:46 +040012 2012, 21:09:46
26

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

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

ответил Robert Harvey 15 FebruaryEurope/MoscowbWed, 15 Feb 2012 21:07:25 +0400000000pmWed, 15 Feb 2012 21:07:25 +040012 2012, 21:07:25
20

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

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

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

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

ответил sim303 7 AMpMon, 07 Apr 2014 01:46:59 +040046Monday 2014, 01:46:59
17

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

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

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

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

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

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

ответил Garrett Hall 15 FebruaryEurope/MoscowbWed, 15 Feb 2012 22:49:42 +0400000000pmWed, 15 Feb 2012 22:49:42 +040012 2012, 22:49:42
12

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

  • Разработка, управляемая поведением - это подмножество 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
ответил percebus 14 Jam1000000amTue, 14 Jan 2014 08:33:21 +040014 2014, 08:33:21
4

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. добавление еще одного уровня абстракции требует большего количества кода ...

ответил inf3rno 22 Mayam15 2015, 00:07:46
2

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

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

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

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

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

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

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

ответил tottinge 22 Maypm15 2015, 20:07:55

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132