Блог

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

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

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

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

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

Я бы использовал оба в двух вложенных циклах, как описано в Behavior-Driven Development с 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
  

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

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

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

Модульные тесты — Изолированные объекты ведут себя надлежащим образом

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

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

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

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

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

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

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

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