有效地进行单元测试/任何人都尝试过组装方法吗？

Question

我正在尝试将单元测试重新引入我的团队，因为我们目前的覆盖范围很差。

我们的系统是40多个项目/组件。我们当前使用名为[SystemName] .Test.csproj的项目，所有测试代码都被转储和组织，以使用文件夹来表示命名空间。这种方法的可扩展性不高，很难找到测试。

我一直在考虑为每个项目添加一个Tests文件夹，这会将单元测试“放在开发人员面前”并使它们易于查找。缺点是生产版本代码将包含对nunit，nmocks以及测试代码和测试数据的引用....有没有人尝试过这种方法？

其他人如何在大型项目上进行单元测试？每个“真实”项目/装配有一个测试项目会引入太多新的项目。

提前致谢

Answer 1

我个人使用项目内方法。 由于单个项目本身就是一个软件模块（因此可以发货或在其他项目中使用），我认为最好的方法是将测试绑定到单个软件模块，因此它会自动跟踪测试的代码。 / p>

Answer 2

我认为这是一个坏主意，因为你说的原因，你最终在生产代码中引用测试程序集，以及所有测试都编译到你的生产代码中的事实，除非你做一些魔术排除它

你没有说为什么测试很难找到。如果它们反映了他们正在测试的东西的结构，那么他们应该比他们正在测试的代码更难找到。

你应该有一个CI服务器，它一直运行所有的测试，因此，即使测试不在开发人员面前，他们也无法从他们轻易破坏构建的事实中解脱出来。

我们倾向于在他们自己的项目中进行测试，但该项目是在他们正在测试的程序集的子测试程序中的Tests（或Tests.Integration或者无论测试是什么）。这样，当检查项目代码并且没有测试项目文件夹在项目级别污染目录结构时，就会获得测试。但是，对于您拥有的每个组件，您最终都会得到至少一个测试项目。我认为这没关系，除非你有很多小型程序集，但在这种情况下你真的需要在ide中一直使用它们中的所有代码，或者你只需​​要为你正在处理的程序集编写代码在本地，并让其他程序集刚刚由dll引用？

Answer 3

我参与了一个大项目（500万行代码，~160,000单元测试），用于将测试类放在每个文件的底部，在一个单独的命名空间中，包含在#if DEBUG中。

NUnit的引用存在于生产中，但测试代码未包含在发布版本中，因此它不会使生产DLL更大。

好处是测试代码就在生产代码旁边，因此找到测试并不困难。还清楚哪些测试属于哪些类，并且不需要尝试模拟测试文件夹中的命名空间层次结构，如果命名空间或类名更改，这总是很麻烦。

这个项目非常成功，但是这些日子的意见和里程可能会有所不同:)我目前工作的地方的结构与Sam Holder描述的结构非常相似。