Включает ли TDD интеграционные тесты?

Золотое правило TDD гласит: никогда не пишите новые функции, не провалив тесты.

Если вы не следуете этому правилу, значит, вы выполняете TDD частично (например, пишете модульные тесты только для нескольких классов в вашем приложении). Это лучше, чем ничего (по крайней мере, вы знаете, что эти классы делают то, что требуется, но вы не можете быть уверены, что другие части приложения работают и эти классы могут быть интегрированы с ними), но это не гарантирует, что ваше приложение работает должным образом. Итак, вам нужно начинать каждую функцию с написания неудачного приемочного теста, который направляет дизайн вашего приложения и определяет поведение приложения (внешний цикл). Пока этот тест не проходит, эта функция не реализована вашим приложением. Затем вы должны написать модульные тесты для отдельных модулей, которые будут задействованы в этой функции (внутренний цикл). Внешний цикл проверяет, что все классы, задействованные в этой функции, работают вместе, как ожидалось. Внутренний цикл проверяет, что каждый класс работает, как ожидалось, сам по себе.

На следующем рисунке из замечательной книги Growing Object-Oriented Software, Guided by Tests показаны эти две петли обратной связи в TDD:

И ответ на ваш вопрос: да - TDD включает интеграционные тесты. Это единственный способ не нарушить золотое правило TDD.

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

Из Разработка через тестирование на примере («Макет объекта " шаблон) :

Решение - не использовать большую часть времени настоящую базу данных.

Тем не менее, это не должно помешать вам написать несколько других тестов, которые при необходимости проверят, хорошо ли работает ваш производственный код с реальной базой данных или дорогостоящим ресурсом:

Что, если фиктивный объект не ведет себя как настоящий? Вы можете уменьшить эту стратегию, имея набор тестов для фиктивного объекта, который также может быть применен к реальному объекту, когда он станет доступным.

В общем, я думаю, что вся интеграция с модульным тестом ортогональна TDD. Другими словами: наличие небольшого цикла обратной связи красный / зеленый / рефакторинга в качестве вашего атомарного строительного блока не определяет, какой вариант общего рабочего процесса разработки приложения вы должны выбрать или какие другие циклы обратной связи должны его окружать - это может быть принято как @lazyberezovsky объяснены, снаружи внутрь или наизнанку, ориентированы на интеграцию или изоляцию и т. д., если вы остаетесь правдивыми в отношении подхода, ориентированного на тестирование.

Я бы сказал, что в «нормальных» циклах tdd, красный - зеленый - рефакторинг, доступ к БД должен быть имитируемым. Для этого используются модульные тесты, и тестируемая часть должна быть как можно меньше. НО, интеграционные тесты необходимы для каждого проекта.

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