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

Ответ 1

Золотое правило TDD гласит: Никогда не пишите новую функциональность без проверки.

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

Следуя рисунку из большой книги "Растущее объектно-ориентированное программное обеспечение", "Руководствуясь тестами" демонстрирует эти две циклы обратной связи в TDD:

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

Ответ 2

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

Из тестовой разработки по примеру (шаблон "Mock object"):

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

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

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

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

Ответ 3

Я бы сказал, что в "нормальных" циклах tdd, red-green-refactor, доступ к db должен быть издеваемым. Что касается этого модульного тестирования, и испытанная часть должна быть как можно меньше. НО, имея интеграционные тесты для каждого проекта, необходимо.

Ответ 4

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