Java单元测试,目录布局

Mik*_*ike 71 java unit-testing

在为Java代码构建一套单元测试时,是否存在将测试代码放在与源代码相关的位置的约定?

例如,如果我有一个/java包含大量.java源文件的目录,那么将测试用例放在/java自身或使用类似的东西更好/java/test.

如果后者是首选,当类的private /protected成员在包外不可用时,如何测试代码的内部?

Sin*_*hot 101

我建议遵循Apache Software Foundation的标准目录结构,这会产生以下结果:

module/
  src/
    main/
      java/
    test/
      java/
Run Code Online (Sandbox Code Playgroud)

这使测试与源分开,但在目录结构中处于同一级别.如果你仔细阅读Apache如何定义它们的结构,你会发现它也有助于分解其他问题,包括资源,配置文件,其他语言等.

假设您将测试用例放在与测试对象相同的包中,此结构还允许单元测试测试被测单元的包和受保护级别方法.关于测试私人方法 - 我不会打扰.其他东西,无论是公共的,打包的还是受保护的,都可以调用它们,你应该能够获得完整的测试覆盖率来测试这些东西.

顺便说一句,上面的链接是Apache的标准构建工具Maven.他们所拥有的每个Java项目都符合这个标准,以及我遇到的每个使用Maven构建的项目.

  • +1即使您不使用maven,也应该遵循这种布局(一种基于行业最佳实践的事实上的标准). (6认同)
  • 这里提到Maven的唯一原因是因为它的网站是记录Apache标准目录布局的地方.你喜欢或不喜欢它与所讨论的目录结构是否合适无关.也许你可以评论一个与你的意见一致的答案,以表明为什么目录结构更优越. (6认同)
  • 好吧,应该提到的是,`main`和`test`文件夹通常都有一个`resources`源文件夹,它编译成`java`文件夹所在的同一输出文件夹,可以轻松地分离Java代码和资源文件.来源水平.我也喜欢这种结构,因为它保持顶层没有多个源文件夹......这是一个非常合乎逻辑的组织.是的,这与是否喜欢Maven无关. (6认同)
  • 八年前我发表了这个评论.我已经成长为理解和爱Maven.我现在不会没有它.人们可以改变. (3认同)

oxb*_*kes 70

您可以将测试放在与原始类相同的包中,即使源代码位于其自己的目录根目录下:

PROJECT_ROOT
    +--- src/
    +----test/
Run Code Online (Sandbox Code Playgroud)

你可以声明一个类com.foo.MyClasssrc其测试com.foo.MyClassTesttest.

至于访问私有成员,你可以使用反射来调用方法(通过改变它们的可访问性Class.getDeclaredMethod.setAccessible),或者你可以使用像testng/junit5这样的东西来对源代码本身进行一些注释驱动的测试(我个人认为这是一个馊主意).

为什么不查看一些项目java.net,看看他们是如何组织的东西,例如swinglabs(我害怕SVN存储库很慢)?


Osc*_*Ryz 8

大部分时间都是这样完成的:

<SOME_DIR>/project/src/com/foo/Application.java
<SOME_DIR>/project/test/com/foo/ApplicationTest.java
Run Code Online (Sandbox Code Playgroud)

因此,您将它们分开,您仍然可以测试包/受保护的功能,因为测试位于同一个包中.

你不能测试私有东西,除非它在类中自己声明.

交付时,您只需打包.class由src生成的,而不是测试


Ale*_*yak 5

实际上,将生产和测试项目分成两个单独的实体很有意义,但是在两个项目中都具有相同的包结构。

因此,如果我有一个项目“ my-project”,我还将创建“ my-project-test”,因此我具有以下目录结构:

my-project
  +--- src/com/foo
my-project-test
  +---test/com/foo
Run Code Online (Sandbox Code Playgroud)

这种方法确保测试代码依赖性不会污染生产代码。

我个人认为,应该对包私有和受保护的方法以及公共方法进行测试。因此,我希望测试类与生产类在同一包中。