通常,不需要模块化您的测试代码(至少我认为没有合理的理由,也许有人可以给出令人满意的反例)。
module-info.java在的主代码中只能存在一个文件(毕竟,甚至不需要模块化主代码)
src。
由于该
module-info.java文件将仅位于您的主源目录中,而不位于测试源目录中,因此从逻辑上讲,它不应依赖于JUnit模块。因此,现在的问题变成了如何依靠模块(代表被测系统)和JUnit模块来编译和运行JUnit测试类。
为此,您需要使用
javac和提供的新选项
java:
因此,假设您具有以下树:
src module-info.java (declares a module called "my.module") mypackage MyClass.javatest_src mypackage MyClassTest.javalib/junit-platform-console-standalone.jar
(注意:专门针对JUnit 5,您可以使用junit-platform-console-
standalone工件,该工件包含核心JUnit引擎并允许在控制台中运行测试;请参阅用户指南)
然后您可以按以下方式编译代码:
cd root_dirjavac -d mods/my.module src/module-info.java src/mypackage/MyClass.javacd test_srcjavac -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_outjava --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即使未在中声明junit,它也仍然需要
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),a
my.module和a
my.test.module,仅后者需要JUnit。
如果确实在模块中包含测试类,则在上述命令中,您不需要
--add-reads和
--patch-module。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)