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

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

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

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


unit-testing integration-testing web-applications testing
person ayang    schedule 15.01.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

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

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

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

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

person krosenvold    schedule 15.01.2009
comment
Я оставил этот вопрос довольно широко открытым, но, думаю, я более конкретно рассматриваю сценарий, более близкий к вашему описанию веб-тестов. И в этом случае похоже, что вы предоставляете свои ресурсы в пути к классам (в отдельной банке). - person ayang; 16.01.2009

arrow_upward
2
arrow_downward

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

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

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

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

person Douglas Squirrel    schedule 15.01.2009

arrow_upward
0
arrow_downward

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

person Arne Burmeister    schedule 15.01.2009