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

Question

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

客户端(包含 View 、 Controller 等)

Client.Tests

通用(包含数据/服务契约(Contract)、通用实用程序等)

Common.Tests

服务器(包含域、服务等)

Server.Tests

服务器.WebHost

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

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

Answer 1

有没有确定的答案因为这完全取决于您的工作以及个人品味。然而，您肯定希望以一种可以有效工作的方式安排事情 .

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

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

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

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

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