Следует ли автоматизировать BDD с помощью модульных тестов, интеграционных тестов или обоих?

Question

BDD рекламировалось как «TDD сделано правильно».

Однако TDD широко используется с тестами unit , а не сквозными интеграционными тестами.

Какой тип теста наиболее подходит для BDD?

• Должны ли мы писать только интеграционные тесты?
• Должны ли мы также писать модульные тесты?
  • Если да, должно ли быть несколько юнит-тестов для каждого сценария?
  • А что юнит-тест охватывает несколько сценариев?Есть ли способ структурировать эти тесты при использовании инфраструктуры тестирования, такой как MSpec?

Answer 1

Какой тип теста (интеграционные тесты, модульные тесты) наиболее подходит для BDD?

Я бы использовал оба в двух вложенных циклах, как описано в Разработка на основе поведенияс SpecFlow и WatiN

* writing a failing integration tests
    * writing a failing unit test as part of the solution of the integration test
        * making the unittest pass
        * refactor
    * writing the next failing unit test as part of the integration test

    * unitl the integration test passes

* writing the next failing integration tests

Answer 2

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

Когда поддельные объекты используются в качестве коллабораторов вместо реальных объектов в модульном тесте, довольно легко проверить, что изолированное тестируемое устройство ведет себя должным образом (то есть, что оно правильно изменяет свое состояние и отправляет правильные сообщения). Однако он не может проверить ничего больше, чем то, что в отдельности отдельный объект ведет себя как ожидалось. Таким образом, необходимо провести сквозное приемочное испытание, чтобы убедиться, что все объекты в системе при совместном использовании обеспечивают обещанное значение для конечного пользователя.

Таким образом, в основном в рамках этого подхода юнит-тесты и приемочные тесты играют следующие роли:

Юнит-тесты - Объекты в изоляции ведут себя надлежащим образом

Приемочные / интеграционные тесты - Все объекты вместе обеспечивают обещанное значение системы.

Хотя я сам являюсь большим сторонником этого стиля разработки, он несколько независим от общих идей BDD. По моему мнению, приемочные / интеграционные тесты необходимы только тогда, когда вы изолируете тестируемую систему в своих модульных тестах, используя макеты и заглушки.

Answer 3

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

Answer 4

Я дам ответ, который кажется мне наиболее вероятным, но я могу быть не в курсе.

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

BDD просто применяет ту же концепцию к системе в целом . Поэтому для BDD вы пишете интеграционные тесты, которые вызывают систему извне, имитируя щелчки мыши и т. Д., Или любой другой интерфейс, используемый конечным пользователем для доступа к системе.

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

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