单元测试应该在哪里？

Question

我对单元测试比较陌生,而且我发现虽然很多消息来源说你应该编写单元测试,但是很少有人给出任何指示将它们放在你的项目中的指示.

我见过的唯一建议是将它们与生产代码放在一起,或构建一个镜像生产代码的目录结构.我在第一种方法中看到的问题是,当你完全构建系统时,很难提取出那些测试; 对于第二个,您将如何测试仅在包级别可见的功能？

是否有合适的方法来组织单元测试,以便您可以轻松地自动化构建过程并仍然可以访问需要测试的所有内容？

编辑:对于那些对特定语言感到疑惑的人,我主要使用Java.但是,我想找到一个与语言无关的解决方案,所以无论我在做什么平台,我都可以应用它.

Answer 1

第二种方法是最好的.为测试创建并行源树.设置您的包结构相同.你没有说你正在使用什么语言,但如果它是Java,那么测试源代码树中的代码将能够很好地访问主源代码树中的代码.包中有一些来自一个源代码树的代码和一些来自另一个源代码树的代码是无关紧要的 - 生产代码和测试代码仍然在同一个包中.

Answer 2

您没有指明您正在使用的平台和工具,这会对选项产生影响.我正在回答.NET和Visual Studio的观点:

我的团队(处理一个相当大的项目)已经成功地使用了将代码和测试放在一起的方法.解决方案中的一个给定的(子)的命名空间,有一个"_Test"文件夹内该(子)命名空间("_"是一个黑客获取Visual Studio来显示它高于一切该命名空间中其他的解决方案浏览器) .

我正在团队中介绍TDD,并认为测试和代码之间的最小摩擦对于采用这种做法的成功至关重要.因此,测试总是"物理上接近"它测试的代码; 你不想在一个巨大的解决方案中寻找前进和转发,以便在代码和测试之间跳转.

当你想到它时,这是有道理的.代码和测试像阴阳一样.这也意味着只有1装配需要1个装配修改类型时重修(我们有超过30个项目在我们的解决方案,因此这有利于我们与构建当前项目只能通过TDD,不断发展的一个类时,安全脱身的方法比快完整解决方案构建).

将代码和测试结合在一起也解决了能够测试内部类的问题.但是,在.NET平台上,如果要将事物分开,也可以使用InternalsVisibleTo Assembly-level属性来授予对单独测试程序集的访问权限.

我可以看到在单独的程序集中进行测试的唯一原因是避免运送该代码.但是,如果您正在使用构建自动化,那么这个方面可以通过另一种方式解决.由于Visual Studio的项目文件是XML,我们只需让构建服务器使用小型XSLT预处理项目文件,从而在Release版本中的编译中删除*/_ Test/*文件夹中的每个文件.

Answer 3

我发现第一种方法的问题是，当您对系统进行完整构建时，提取这些测试将变得困难

您始终可以根据某些命名约定来过滤类，例如打包时的特殊后缀或前缀（例如，不包含**/*Test.class在 Java 中）。但我不太喜欢这种方法，我发现它很混乱且脆弱。

对于第二个问题，您将如何测试仅在包级别可见的功能？

除非我遗漏了什么，否则我看不到这个问题。您可以将类放在同一个包中，并将它们放在不同的树中，例如：

• src/main/java对于应用程序源
  • src/main/java/foo/Bar.java
• src/test/java用于测试源
  • src/test/java/foo/BarTest.java

两者Bar.java都BarTest.java在同一个foo包中，但在不同的目录中。这是我使用的方法。

是否有一种合适的方法来组织单元测试，以便您可以轻松地自动化构建过程并仍然访问需要测试的所有内容？

好吧，正如所暗示的，我的测试源和应用程序源位于同一个项目中，但位于不同的目录树中，这对我来说非常有用。

这实际上是 Maven 建议的默认布局（请参阅标准目录布局简介）。无论您使用什么语言，这都可能会给您一些想法。