Модульное тестирование и веб-приложения - ресурсы

Question

Как в веб-приложении J2EE люди управляют ресурсами, чтобы они были видны как для веб-контекста, так и для модульных / интеграционных тестов?

Я обнаружил, что часто вы в конечном итоге настраиваете папки с исходными файлами / ресурсами определенным образом во время разработки (то есть, что ожидает Maven), и поэтому ваши модульные тесты будут выполняться в вашей IDE. Но как только веб-приложение будет собрано и упаковано в WAR-файл (т. Е. Когда ваш сервер Continuous Integration выполнил сборку), ваши модульные тесты больше не будут запускаться, поскольку ресурсы расположены в другом месте.

В конечном итоге вы храните ресурсы в двух разных местах и ​​синхронизируете их вручную?

Answer 1

Мы пытались использовать модульные тесты в контейнере, но отказались от него несколько лет назад. Намного лучше (по крайней мере для нас), чтобы каждый модульный тест охватывал один класс и ничего больше, высмеивая зависимости от других классов (см. JMock или его многочисленных конкурентов). Хорошим базовым правилом является то, что если оно касается базы данных, сети или файловой системы, это не является модульным тестом. (Это может быть полезно для чего-то другого, но это не модульный тест. Подробнее об этом см. в этих правилах модульного тестирования .)

Юнит-тесты, написанные таким образом, можно запускать где угодно, и они невероятно быстрые (у нас их тысячи и мы выполняем их менее чем за 60 секунд на оборудовании средней спецификации.)

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

(Кстати, наш метод модульного тестирования делает нас mockists, , а не classicists, in Таксономия Мартина Фаулера .)

Answer 2

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

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

Весьма распространено, что модуль, который приводит к WAR, вообще не имеет никакого Java-кода, а только артефакты, связанные с сетью. Хотя это и не обязательно, это часто делается, потому что код, находящийся в военном модуле, не может быть включен в другой модуль.

Последний особый случай - модуль, содержащий веб-тесты. Этот модуль может часто нуждаться в артефактах тестовой области из других модулей (потому что он тестирует приложение извне, но может нуждаться в данных изнутри). Эту проблему можно решить путем упаковки ресурсов test в jar-файлы, создав отдельный набор jar-файлов test для каждого модуля.

Мультимодульные сборки являются нормой для maven проектов, а также легко настраиваются для других систем сборки, таких как ant.

Answer 3

Я не буду упаковывать ресурсы тестирования, ни тесты в файле WAR, ни запускать модульные тесты из WAR. Почему вы пытаетесь это сделать?