Где мне провести черту между юнит-тестами и интеграционными тестами? Должны ли они быть отдельными?

У меня есть небольшой MVC-фреймворк, над которым я работаю. Его кодовая база определенно не большая, но это не просто пара классов. Я наконец решил сделать решающий шаг и начать писать тесты для него (да, я знаю, что должен был делать это все время, но его API до сих пор был очень нестабильным)

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

Ложный объект HTTP-запроса -> Структура MVC -> Объект HTTP-ответа -> Проверка правильности ответа

Поскольку все это выполнимо без каких-либо состояний или специальных инструментов (автоматизация браузера и т. Д.), Я мог бы на самом деле легко сделать это с обычными модульными тестовыми средами (я использую NUnit).

Теперь большой вопрос. Где именно я должен провести черту между юнит-тестами и интеграционными тестами? Должен ли я тестировать только один класс за раз (насколько это возможно) с юнит-тестами? Кроме того, следует ли размещать интеграционные тесты в том же проекте тестирования, что и мой проект модульного тестирования?

Интеграция против юнит-тестов

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

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

Поскольку вы тестируете в полной изоляции во время модульного тестирования, вы используете объекты-заглушки и макеты, чтобы вести себя как остальная часть вашего приложения. Вот тут-то и вступают интеграционные тесты. Тестирование всех модулей изолированно, но вам нужно знать, действительно ли модули работают вместе.

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

Тестовая разработка

Сделав шаг назад и взглянув на Test Driven Development (TDD), следует принять во внимание несколько моментов.

1. Вы пишете свой модульный тест, прежде чем на самом деле написать код, который делает его успешным.
2. Вы проходите тестирование и пишете достаточно кода для этого.
3. Теперь, когда тест пройден, настало время сделать шаг назад. Есть ли что-то, что можно изменить с помощью этой новой функциональности? Вы можете сделать это безопасно, так как все покрыто тестами.

Интеграция первая против интеграции последняя

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

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

практические вопросы

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

Кстати, мы обычно используем один тестовый файл для одного класса.

Предлагаемое чтение

1. Растущее объектно-ориентированное программное обеспечение, ориентированное на тесты. Эта книга является чрезвычайно хорошим примером методологии интеграционных тестов.
2. Искусство юнит-тестирования, с примерами в dot.net О юнит-тестировании, с примерами в dot.net: D Очень хорошая книга о принципах юнит-тестирования.
3. Роберт К. Мартин на TDD (бесплатные статьи): Прочтите также первые две статьи, на которые он ссылался.

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

В целом, и если у вас нет особых требований к обратному (например, DO178 уровня A, IEC61508 SIL 4 и т. Д.), Что не соответствует действительности в вашей ситуации, тогда, если вы можете протестировать полную функцию класса или модуля (и продемонстрируйте, что у вас есть) на системном уровне, тогда тестирование на системном уровне является адекватным. И так далее вниз. Модульное тестирование необходимо только в том случае, если вы не рассмотрели тестирование дальше.

Где именно я должен провести черту между юнит-тестами и интеграционными тестами?

Учитывая, что тестирование интеграции обычно проще, быстрее и дешевле, проведите линию так далеко, как только сможете ...

Должен ли я тестировать только один класс за раз (насколько это возможно) с юнит-тестами?

Опять же, это зависит от объема ... по определению, модульное тестирование - это тестирование одного модуля. Но если вы можете полностью протестировать полный модуль за один раз, то при желании сделайте это. Фактически вы выполняете несколько юнит-тестов за один удар.

Кроме того, следует ли размещать интеграционные тесты в том же проекте тестирования, что и мой проект модульного тестирования?

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

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

В модульных тестах я обычно тестирую только один класс (SUT) в файле.