每个解决方案的单一与多单元测试项目？

Question

我的产品组件和单元测试组件之间通常有1：1的映射关系。我通常会尝试将组件的总数保持在较低水平，典型的解决方案可能看起来像......

• 客户端（包含视图，控制器等）
• Client.Tests
• 通用（包含数据/服务合同，常用功能等）
• Common.Tests
• 服务器（包含域名，服务等）
• Server.Tests
• Server.WebHost

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

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

Answer 1

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

对我而言，这意味着，我想快速找到一些东西，我想看看测试什么，我想运行较小的东西以便更好地控制，以防我想要在测试中进行分析或做其他事情。当您调试失败的测试时，这通常很好。我不想花费额外的时间来解决任何事情，它应该说明事物是如何映射的以及属于什么的。

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

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

在尝试各种方法后，这是我个人的选择。

在我看来，当有太多东西时将事物分组并不一定是好事。它可以，但我相信在这个讨论的背景下，它是单个测试项目的错误论据。包含许多文件的测试项目太多意味着只有一个包含大量测试文件的测试项目。我相信真正的问题是你正在努力解决的问题是变大。也许还有其他事情可以避免“一个世界”？ ：）

Answer 2

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

假设一个单一的解决方案，其中一个测试项目涵盖了该解决方案中的所有内容，那么就会出现故障。

Answer 3

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

Answer 4

我不确定某个特定标准，但在我看来，将它们分成单独的测试项目似乎是一种更好的做法。在我看来，它与解决方案/项目级别的面向对象编程非常相似。假设您的某个项目需要在某个地方重复使用，并且您希望能够随身携带您的测试。如果它们与其他测试位于一个单独的项目中，并且仅对该特定项目是独占的，那么您也只需转移该项目。否则你必须通过质量检测项目进行捕捞。

此外，项目分离有助于在调试时保持整洁。而不是必须破解一个大型项目并挖掘你需要的测试文件，如果你有一个匹配的功能项目测试项目，那就简单得多了......显着缩小你的搜索范围。

同样，我认为这是一个偏好的事情，我从来没有听说过这种或那种方式的明确解决方案，但是我有两分钱......

Answer 5

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

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

单元测试 - ＆gt;模型

单元测试 - ＆gt;业务逻辑 - ＆gt;模型

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

Answer 6

我实际上可能会说，如果你考虑在不同的项目中拆分你的测试以测试一个组件，那么那个组件太大了。我通常将我的项目拆分成小的，可重用的组件，小的，1-1映射测试。这当然可能会导致DLL溢出，并且对于某些项目（例如Web项目，将控制器拆分为不同的程序集时，逻辑上不干净）可能并不总是可能。只是一个想法。

Answer 7

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