(по крайней мере, я не могу придумать вескую причину, может быть, кто-то может привести удовлетворительный контрпример). Единственныйmodule-info.java файл может (в конце концов, даже не требуется модулировать ваш основной код) присутствовать в вашем основном коде вsrc.

Посколькуmodule-info.java Файл будет находиться только в вашем основном исходном каталоге, а не в тестовом исходном каталоге, тогда логически он не должен зависеть от модуля JUnit. Поэтому теперь возникает вопрос, как скомпилировать и запустить тестовые классы JUnit, полагаясь на модуль (представляющий тестируемую систему) и модуль JUnit.

Для этого вам нужно будет использовать новые опции, предоставляемыеjavac а такжеjava:

Итак, если у вас есть следующее дерево:

src
    module-info.java (declares a module called "my.module")
    mypackage
        MyClass.java
test_src
    mypackage
        MyClassTest.java
lib/junit-platform-console-standalone.jar

(примечание: специально для JUnit 5 вы можете использовать артефакт junit-platform-console-standalone, который содержит ядро ​​JUnit и позволяет запускать тесты в консоли; см.руководство пользователя)

тогда вы можете скомпилировать код следующим образом:

cd root_dir
javac -d mods/my.module src/module-info.java src/mypackage/MyClass.java

cd test_src
javac -d test_out --module-path ../mods;../lib/junit-platform-console-standalone.jar \
--add-modules org.junit.platform.console.standalone,my.module --patch-module my.module=. \
--add-reads my.module=org.junit.platform.console.standalone mypackage/MyClass.java

и вы можете запустить скомпилированный тестовый класс:

cd test_src/test_out
java --module-path=../../mods;../../lib/junit-platform-console-standalone.jar \
--add-modules my.module,org.junit.platform.console.standalone \
--add-reads my.module=org.junit.platform.console.standalone \
--patch-module my.module=. \
--add-opens my.module/test=org.junit.platform.console.standalone \ 
org.junit.platform.console.ConsoleLauncher test.MyClassTest

Неуклюжие команды, но это стоимость не использования Maven. Я советую вам прочитать об этих параметрах в документации к командам после понимания концепции пути модуля. Здесь важно отметить несколько вариантов:

--patch-module my.module=.

Это необходимо, потому что пример кода теста имеет тот же пакет (mypackage) как модульmy.module, Без этого система модуля будет жаловаться.

--add-reads my.module=org.junit.platform.console.standalone

Это делает джунит необходимым дляmy.module хотя это не было объявлено вmodule-info.java.

org.junit.platform.console.standalone это имяавтоматический модуль и выводится из манифеста Jar (как в случае с JUnit 5), в противном случае - из имени файла Jar (например, в случае JUnit 4).

Также обратите внимание, что именно это Maven, вероятно, делает за кулисами при компиляции и запуске модульных тестов (см.Эта проблема для эквивалентной конфигурации плагина, которая выполняет вышеописанное вручную).

Что если по какой-то причине вы также захотите модульные тесты?

В этом случае, поскольку в приведенном выше примере модульные тесты используют один и тот же пакет, вы можете включить их вmy.module и добавьте требование к JUnit:

module my.module {
    exports mypackage;
    requires org.junit.platform.console.standalone;
}

Если модульные тесты были в другом пакете, вы также можете разделить их на два модуля (дваmodule-info.java),my.module иmy.test.module где только последний требует JUnit.

Если вы включаете тестовые классы в модуль, то в приведенных выше командах вам не нужно--add-reads а также--patch-module.