Контейнерное тестирование и фиктивные объекты для интеграционного тестирования

Question

Тестирование внутри контейнера часто противоположно тестированию с фиктивными объектами.Однако, поскольку фиктивные объекты просто имитируют поведение реальных объектов, не является ли тестирование в контейнере единственным способом действительно протестировать систему в ее «реальной среде»?

Как частичная альтернатива в контейнередля тестирования и проверки объектов Spring предоставляет инфраструктуру TestContext, которая прекрасно инициализирует Spring без необходимости запуска фактического контейнера приложения (в моем случае, сервера веб-приложений).Однако это несколько ограниченный подход, поскольку он только инициализирует специфичные для Spring функции, в то время как специфичные для сервера приложений функции не поддерживаются.Таким образом, вы не можете проверить все.Кроме того, поскольку он не на 100% совпадает со значением по умолчанию WebApplicationContext, которое используется в реальном веб-исполнении, не является ли этот подход немного хакерским?Это плохо?

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

Подводя итог: следует ли проводить тестирование в контейнере или в контейнере и почему?Не хотите ли использовать фиктивные объекты или альтернативный механизм инициализации (как в Spring TestContext) для своих интеграционных тестов?

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

Answer 1

Однако, поскольку фиктивные объекты просто имитируют поведение реальных объектов, не является ли тестирование в контейнере единственным способом действительно протестировать систему в ее «реальной среде»?

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

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

Мы изолировали наши внутриконтейнерные / интеграционные тесты в другом месте в другом проекте сзависимости от кода проектов.Они разработаны, чтобы максимально имитировать производственные конфигурации - насколько это возможно.Эти тесты занимают больше времени для настройки, запускаются дольше и более полезны для выполнения чего-то вроде cruisecontrol .Они запускаются вручную, особенно когда мы приближаемся к выпуску или после стабилизации разработки.Часто я запускаю интеграционные тесты, когда иду на обед или на встречу.Когда интеграционный тест обнаруживает ошибку, мы пытаемся написать модульный тест, который также демонстрирует ошибку с макетами - это часто бывает сложно и может быть невозможно.

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

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

Answer 2

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

Что касается насмешек, я считаю, что они могут сыграть свою роль в интеграционном тестировании с Spring, но я с большей вероятностью буду использовать поддельные / тупые сервисы с постоянными результатами для интеграции и тестирования в контейнере вызов системы тестирования).

Если вы не уверены, в чем разница между издевательством и окурком, посмотрите эту статью Мартина Фаулера .