单元测试应该放在哪里?

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

在打包时,您可以始终根据一些命名约定(如特殊后缀或前缀)筛选类(例如,不包括 **/*Test.class

第二,如何测试只在包级别可见的功能?

除非我遗漏了什么,否则我看不出问题所在。你可以在教室里上课 让他们住在 ,例如:

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

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

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

嗯,正如暗示的,我的 测试源 和 应用程序源 住在 相同的 项目但在 不同的

这实际上是Maven建议的默认布局(参见 Introduction to the Standard Directory Layout ). 不管你用什么语言,这可能会给你一些想法。

第二种方法是最好的。为测试创建一个并行源代码树。同样设置包结构。你不会说你在用什么语言,但是如果它是Java,那么测试源代码树中的代码就可以访问主源代码树中的代码了。包中有些代码来自一个源代码树,有些代码来自另一个源代码树这一事实与此无关——生产代码和测试代码仍然在同一个包中。

你没有指出你正在使用的平台和工具,这对选项有影响。我从.NET和Visual Studio的角度回答:

我的团队(在一个相当大的项目中工作)已经成功地使用了放置代码和测试的方法 在一起 . 对于解决方案中的给定(子)命名空间,有一个“\u Test”文件夹 里面 这个(子)名称空间,(“\”是一种让visualstudio在解决方案浏览器中将它显示在名称空间中的所有内容之上的方法)。

我在队里介绍TDD的时候觉得 最小摩擦力

当你想起来的时候,这是有道理的。代码和测试就像阴阳一样属于一起。这也意味着在修改一个程序集中的类型时,只需要重建一个程序集(我们的解决方案中有30多个项目,因此只有在通过TDD演化类时,我们才能安全地完成当前的构建项目, 方式 比完整的解决方案构建更快)。

我可以看到,在单独的程序集中进行测试的唯一原因是为了避免发送该代码。但是,如果您使用的是构建自动化,则可以通过另一种方式轻松地解决这个问题。由于visualstudio的项目文件是XML,我们只需让构建服务器使用一个小型XSLT对项目文件进行预处理,就可以将*/\u Test/*文件夹中的所有内容从发布版本的编译中剥离出来。

在项目树上只为测试项目设置一个文件夹也是一个好主意。这样,如果您需要在不进行测试的情况下构建系统,那么您应该在不构建测试的情况下进行构建配置,尽管构建测试并将其作为CI(持续集成)的一部分运行是一个好主意,而不仅仅是将生产代码打包到安装程序中或将其复制到特定文件夹中。

测试只在包级别可见的功能是可能的,这取决于所使用的技术—例如.NET能够通过使用 内部可见

这可能取决于你现在使用的是什么。在visualstudio/.net中,通常的做法似乎是为每个产品dll创建一个测试dll,并在dll中模糊地镜像类和测试类。对于ruby/python等,是一个独立的测试目录,在这个目录中有一个层次结构,它反映了正在测试的东西。

“提取”这些测试是什么意思?对于您来说,完整的构建是否涉及编译和运行测试?

包级别的可见性可能是一个问题。我想如果你的测试是在不同的包中,你只需要对直接可见的东西进行测试,但这将间接测试内部的东西。

是什么 是什么

让我们思考一下测试是如何融入到图片中的。。。

• 测试并不直接适用于公众关心的任何事情——他们只是希望它能起作用
• 测试是针对开发人员的,通常是针对企业的
• 测试可以和模块在相同的规模上进行,但是处于二分法的配置中
• 如果测试文件可以在给定的封装结构中与其模块并排存在,那么在逻辑上——在 --测试的一小部分也必须分布在 对象比例 在给定的模块内(想想看, --在哪里 system == component && component == system && (system == system || system == subsystem ) )

最后一个是传达测试本质上与模块是分离的,逻辑上并不是在每个尺度上都互相补充——为了真正理解这一点,我敦促你们学习 分形 & 自对称 , 类型论 和 范畴论 .

然而,应用程序细节可以极大地改变您的选择。。。

从JavaScript的角度来看,一个不可知论的观点,甚至使用了一个高级的架构方案——似乎在 /src 当src目录中有多个测试时,对其他开发人员来说是逻辑上的限制。你呢 想要保护和 你测试,私有化他们给你的团队成员,而不是任何人与你的应用程序公开互动。

也就是说,如果你能确保应用程序的安全性,那么根据应用程序的具体情况走这条路还是值得的;不会产生 不必要的 复杂性,或扼杀自动化。

一些 利用这种方法 ,但它仍然可能以安全性、自动化和生产率(因此对业务)为代价。

/app
    |-lib
    |-src
    |-test

.. 你可能 出问题了。