每个解决方案是单个还是多个单元测试项目？

Question

我的产品程序集和单元测试程序集之间通常有 1:1 的映射。 我通常尽量保持较低的程序集总数，典型的解决方案可能看起来像......

• 客户端（包含视图、控制器等）
• 客户端测试
• 通用（包含数据/服务合同、通用实用程序等）
• 通用测试
• 服务器（包含域、服务等）
• 服务器.测试
• 服务器.WebHost

最近在工作中，人们一直在提到只有一个单元测试项目，而不是通过他们正在测试的程序集来分解它们。 我知道在那天，如果您将 NCover 等作为构建的一部分运行（当然不再重要），这会让生活更轻松。

单个与多个 UnitTest 项目背后的一般理由是什么？ 除了减少解决方案中的项目数量之外，是否有具体的理由采取一种或另一种方式？ 我的印象是这可能是那些“偏好”之一，但谷歌搜索并没有出现太多。

Answer 1

没有明确的答案，因为这完全取决于您的工作以及个人品味。 但是，您肯定希望以某种方式安排事情，以便您可以有效地工作。

对我来说，这意味着，我想快速找到东西，我想看看什么测试什么，我想运行更小的东西来更好地控制，以防我想在测试中分析或做其他事情。 当您调试失败的测试时，这通常很好。 我不想花额外的时间去弄清楚任何事情，它应该自己说明事物是如何映射的，什么属于什么。

对我来说另一个非常重要的事情是，我想尽可能地隔离并有明确的界限。 您想提供一种简单的方法来将大项目的一部分重构/移出到一个独立的项目中。

就我个人而言，我总是围绕我的软件的结构来安排我的测试，这意味着类与其测试、库和测试可执行文件之间的一对一映射。 这为您提供了一个很好的测试结构，它反映了您的软件结构，从而为查找内容提供了清晰度。 此外，它提供了一个自然的分割，以防某些东西被独立移出。

这是我尝试了各种做事方式后的个人选择。

在我看来，当东西太多时分组并不一定是件好事。 可以，但我相信在本次讨论的上下文中，这是针对单个测试项目的错误论点。 太多包含许多文件的测试项目意味着只有一个包含大量测试文件。 我相信真正的问题是你正在研究的解决方案越来越大。 也许您还可以做其他事情来避免“同一个世界”？ :)

Answer 2

除了其他（好的）答案之外，请考虑在较大的项目团队中，个别团队成员可能会创建自己的解决方案，以仅包含他们正在处理的项目子集。

假设一个单一的解决方案，其中一个测试项目涵盖了该解决方案中的所有内容，在这种情况下会崩溃。

Answer 3

我要说的部分原因是它迫使您只招募您正在测试的程序集。 所以你的单元测试不会意外地变成集成测试或更糟。 它有助于确保关注点分离。

Answer 4

如果您在架构的较低层中测试功能，那么拥有一个 UnitTest 项目可能会大大减慢您的速度。 你会花更多的时间等待编译器完成而不是实际编写代码。 想象一个单元测试项目将依赖于所有项目。 这些项目相互依赖。 较低层项目的代码更改可能会导致重新编译该项目上层的项目。 如果您触发单元测试，可能会发生这种情况

例如，如果您有依赖于模型项目的业务逻辑。 你改变你的模型项目。 测试项目取决于业务逻辑和模型。

单元测试 -> 模型

单元测试 -> 业务逻辑 -> 模型

但您只测试模型中的更改。 现在，尽管您只更改了模型，但模型和业务逻辑都可能会重新编译。 这发生在我的一个更复杂的项目中，并更改为每个生产项目有一个测试项目有所帮助。

Answer 5

我不确定特定标准，但在我看来，将它们拆分为单独的测试项目似乎是更好的做法。 在我看来，它与解决方案/项目级别的面向对象编程非常相似。 假设您的一个项目需要在某处重复使用，并且您希望能够随身携带您的测试。 如果它们与其他测试位于不同的项目中，并且仅适用于该特定项目，则您也只需将该项目也一起转移即可。 否则，您必须通过大规模测试项目进行文件钓鱼。

此外，项目的分离有助于在调试时保持整洁。 不必打开一个庞大的项目并去挖掘您需要的测试文件，如果您有功能项目的匹配测试项目，那就简单多了……大大缩小了您的搜索范围。

再说一次，我认为这是一种偏好，我从来没有听说过以某种方式确定的解决方案，但是我的两分钱值...

Answer 6

我实际上可能会极端地说，如果您考虑将测试拆分为不同的项目来测试一个程序集，那么该程序集就太大了。 1 映射测试。 这当然可能会导致 DLL 溢出，并且对于某些项目（例如 Web 项目，将控制器拆分为不同的程序集在逻辑上不那么干净）可能并不总是可能的。 只是一个想法。

Answer 7

我们正在尝试一个单独的测试解决方案，其中所有测试项目都与项目解决方案在 1-1 的基础上进行。