Заменяет ли BDD или увеличивает TDD?

Question

Использует ли BDD TDD или оба используются вместе? Я читал, что BDD должен проверять только те вещи, которые пользователь видит. Если это так, означает ли это, что нужно использовать TDD для методов обслуживания, которые пользователь не увидит?

Answer 1

BDD является заменой как TDD, так и ATDD (и их производных).

Первый инструмент для BDD, JBehave, фактически начался в качестве замены для модуля тестирования JUnit. Предполагалось, что это позволит вам описать поведение вашей (еще не написанной) системы и предоставить примеры, не используя слово «тест», так как на самом деле на этом этапе это анализ, а не тестирование. Это слово, «тест», вызывало все виды замешательства!

Разница заключается в том, что примера и поведение и спецификация все проблемы пространства языка, в то время как слово теста это решение-пространство. Это, как правило, заставляет людей думать, что они понимают проблему, и тестируют решение, которое является проблемой, если они этого не делают!

Оказалось, что избегая слова test помогает людям более подробно изучить проблему. Вы можете прочитать об этом в Dan North's original article.

В то время как Дэн изучал BDD в 2003/4 году, он объяснил это Крису Матцу, который работал в то время в качестве бизнес-аналитика. Крис сказал: «Но это точно так же, как анализ!» И поэтому они начали изучать, как Крис проводил анализ на всех системах, и как это работает, и Крис понял, что речь идет не только о поведении и результатах, а о поведении и результатах в контексте. Это сформировало синтаксис «Given, When, Then», который мы теперь знаем сегодня (он тогда не назывался Gherkin, потому что Cucumber не существовал).

Итак, Дэн начал писать сценарий, работающий на платформе, поверх инструмента «тестирование», а затем перенес его в Ruby как RBehave, который затем превратился в простой текст и стал Cucumber. В этот момент BDD стал заменой ATDD (который обычно делался тогда с невероятно процедурными сценариями, использующими инструменты модульного тестирования).

На самом деле не имеет значения, используете ли вы JUnit, NUnit или какие-либо другие схемы модульного тестирования на низком уровне. Если вы думаете о примерах поведения и говорите по этим примерам, то вы делаете BDD. Написание примеров вниз полезно, и автоматизировать их тоже полезно, поэтому именно такие инструменты BDD, как JBehave и Cucumber, работают на системном уровне.

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

Разница заключается в легкости, с которой люди могут разговаривать, не используя слово «тест».

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

Answer 2

BDD не заменяет TDD, я бы сказал, что он дополняет BDD.

Все зависит от вопроса, будет ли это заниматься бизнесом или нет?

Вы хотите использовать правильный инструмент для работы. То есть, некоторые вещи очень хорошо подходят для BDD, а некоторые другие вещи лучше подходят для TDD. Когда все сделано правильно, линия между BDD и TDD очень размыта. Если он даже существует.

Я написал пост в блоге, где я обсудить концепцию под названием «Тестирование Айсберг», http://www.thinkcode.se/blog/2016/07/25/the-right-tool-for-the-job

может поделиться дополнительный свет на ваш вопрос.

И я согласен с @Lunivore в том, что выбор инструмента менее важен по сравнению с пониманием проблемы, которую вы получаете из разговоров.