Существуют различия и ограничения в вариантах, предлагаемых @Steve C и @ ashosborne1. Думаю, они должны быть указаны.
Когда мы можем использовать: File resourcesDirectory = new File("src/test/resources");
?
- 1 Когда тесты будут запускаться только через maven, но не через IDE.
- 2.1 Когда тесты будут запущены через maven или
- 2.2 через IDE и только один проект импортируется в IDE. (Я использую «импортированный» термин, потому что он используется в IntelliJ IDEA. Я думаю, что пользователи eclipse также импортируют свой проект maven). Это будет работать, потому что рабочий каталог при запуске тестов через IDE совпадает с вашим проектом.
- 3.1 Когда испытания будут выполняться через maven или
- 3.2 через IDE, и более чем один проект импортируется в IDE (когда вы не учащийся, вы обычно импортируете несколько проектов), И перед запуском тестов через IDE вы вручную настраиваете рабочий каталог для своих тестов. Этот рабочий каталог должен ссылаться на ваш импортированный проект, содержащий тесты. По умолчанию рабочий каталог всех проектов, импортированных в IDE, является только одним. Вероятно, это ограничение только
IntelliJ IDEA
, но я думаю, что все IDE работают так. И эта конфигурация, которая должна выполняться вручную, совсем не хороша. Работа с несколькими тестами, существующими в разных проектах maven, но импортированными в один большой проект «IDE», заставляет нас помнить об этом и не позволять расслабляться и получать удовольствие от вашей работы.
Решение, предлагаемое @ ashosborne1 (лично я предпочитаю этот), требует 2 дополнительных требований, которые должны быть выполнены до запуска тестов. Вот список шагов, чтобы использовать это решение:
Создать тестовую папку («Teva») и файл («ридми») внутри «SRC/тест/ресурсы /»:
Src/test/resources/teva/readme
Файл должен быть создан в тестовой папке, иначе это не сработает. Maven игнорирует пустые папки.
- Как минимум один раз построить проект через
mvn clean install
. Он также проведет тесты. Может быть достаточно запустить только ваш тестовый класс/метод через maven без создания целого проекта. В результате ваши тестовые ресурсы будут скопированы в тестовые классы, вот путь: target/test-classes/teva/readme
- После этого вы можете получить доступ к папке с помощью кода, уже предлагаемого @ ashosborne1 (извините, что я не мог редактировать этот код внутри этого списка элементов корректно):
public static final String TEVA_FOLDER = "teva"; ...
URL tevaUrl = YourTest.class.getClassLoader().getResource(TEVA_FOLDER);
String tevaTestFolder = new File(tevaUrl.toURI()).getAbsolutePath();
Теперь вы можете запустить тест через IDE столько раз, сколько вы хотите. Пока вы не запустите mvn clean. Он удалит целевую папку.
Создание файла внутри тестовой папки и запуск maven в первый раз, прежде чем вы запускаете тесты через IDE, необходимы шаги. Без этих шагов, если вы только в своей среде IDE создадите тестовые ресурсы, затем напишите тест и запустите его только через IDE, вы получите сообщение об ошибке. Выполнение тестов через mvn копирует тестовые ресурсы в целевые/тестовые классы/teva/readme, и они становятся доступными для загрузчика классов.
Вы можете спросить, зачем мне импортировать более одного проекта maven в IDE и почему так много сложного? Для меня одна из основных причин: хранить файлы, связанные с IDA, вдали от кода. Сначала я создаю новый проект в своей среде IDE. Это поддельный проект, который является только владельцем файлов, связанных с IDE. Затем я импортирую уже существующие проекты maven. Я заставляю эти импортированные проекты хранить файлы IDEA только в моем оригинальном поддельном проекте. В результате я не вижу файлы, связанные с IDE, среди кода. SVN не должен их видеть (не предлагайте настроить svn/git, чтобы игнорировать такие файлы, пожалуйста). Также это очень удобно.
Из любопытства: зачем вы хотите знать? – fge
@fge необходимо передать его тестируемому объекту, который использует его для загрузки файла – Rory
@fge У меня был аналогичный случай для JBoss - получить имя приложения (war file) приложения для чтения конфигурации из/etc/mycompany/deployment_name/config (у нас есть много экземпляров одного и того же приложения, развернутого в одно и то же время). – Nikolay