在构建Java代码的单元测试套件时,是否有惯例来确定测试代码放置的位置?
例如,如果我有一个包含许多.java
源文件的目录 /java
,是将测试用例放置在 /java
中好还是使用诸如 /java/test
的其他目录更好。
如果后者更可取,那么当类的 private
/ protected
成员在包外不可用时,如何测试代码的内部?
在构建Java代码的单元测试套件时,是否有惯例来确定测试代码放置的位置?
例如,如果我有一个包含许多.java
源文件的目录 /java
,是将测试用例放置在 /java
中好还是使用诸如 /java/test
的其他目录更好。
如果后者更可取,那么当类的 private
/ protected
成员在包外不可用时,如何测试代码的内部?
我建议跟随Apache软件基金会的标准目录结构,这将产生以下结果:
module/
src/
main/
java/
test/
java/
这样可以将测试与源代码分离,但在目录结构中保持相同级别。如果你阅读Apache如何定义他们的结构,你会发现它也有助于将其他关注点分开,包括资源、配置文件、其他语言等。
这种结构还允许单元测试来测试被测试单元的包和受保护级别方法,只要你把测试用例放在与所测试内容相同的包中。至于测试私有方法,我不会去烦恼。其他某些东西(公共的、包内的或受保护的)会调用它们,你应该能够通过测试这些东西来获得完整的测试覆盖率。
顺便说一下,上面的链接是指Maven,Apache的标准构建工具。他们所有的Java项目都符合此标准,我遇到的每个使用Maven构建的项目都是如此。
即使源代码位于自己的目录根目录下,您也可以将测试放在与原始类相同的包中:
PROJECT_ROOT
+--- src/
+----test/
你可以在src
下声明一个com.foo.MyClass
类,它的测试com.foo.MyClassTest
可以在test
下进行。至于访问私有成员,你可以使用反射来调用方法(通过Class.getDeclaredMethod.setAccessible
更改其访问权限),或者你可以使用像testng / junit5这样的工具将一些基于注释的测试放在源代码本身上(我个人认为这是个坏主意)。为什么不去看看一些在java.net上的项目,比如 swinglabs(我恐怕SVN存储库非常慢)?大多数情况下是这样完成的:
<SOME_DIR>/project/src/com/foo/Application.java
<SOME_DIR>/project/test/com/foo/ApplicationTest.java
因此,您将它们分开,仍然可以测试包/受保护的功能,因为测试位于相同的包中。
除非私有内容在类内部声明,否则无法测试私有内容。
交付时,只需打包由src生成的.class
文件,不包括测试文件。
将生产和测试项目分开成两个单独的实体,但是在两个项目中保持相同的包结构是有很多道理的。
因此,如果我有一个项目“my-project”,我还会创建“my-project-test”,这样我就有了以下目录结构:
my-project
+--- src/com/foo
my-project-test
+---test/com/foo
build/
src/
test/build/
test/src/
所有测试代码编译到自己的构建目录中。这是因为我们不希望生产环境中错误地包含测试类。
[module]
+ src/main/java/[com/foo/bar]
[module].iml
文件,您将找到该路径以及测试路径,您可以利用。以下是摘要:<module>
<component>
<content>
<sourceFolder url="file://$MODULE_DIR$/src/main/java" isTestSource="false" />
<sourceFolder url="file://$MODULE_DIR$/src/main/resources" type="java-resource" />
<sourceFolder url="file://$MODULE_DIR$/src/test/java" isTestSource="true" />
<sourceFolder url="file://$MODULE_DIR$/src/test/resources" type="java-test-resource" />
</content>
</component>
</module>
[module]
+ src/main/java/[com/foo/bar]
+ src/test/java/[com/foo/bar]
main
和test
文件夹都有一个名为resources
的源文件夹,其编译成与java
文件夹相同的输出文件夹,这样在源代码级别上可以轻松分离 Java 代码和资源文件。我喜欢这种结构,因为它使得顶层文件夹不会有多个源文件夹...这是一个非常合理的组织方式。是的,这与是否喜欢 Maven 没有任何关系。 - ColinD