.net - 在 .NET 中存储单元测试的常用方法

Question

可能重复：
哪个更好？每个解决方案或每个项目的单元测试项目？

我不时看到不同的方法：

有人将 unittest 存储在他们当前正在测试的同一个项目中，只是在项目根目录下创建测试文件夹。

有人从他们测试的解决方案中为每个项目创建额外的测试项目。

有人对整个解决方案中的所有测试都有一个大的测试项目。

那么在 .NET 世界中存储测试的一般方式是什么，可以说是“官方”方式？很确定微软有这方面的指导方针。

score 2 · Accepted Answer

测试代码的第一条规则：永远不要将测试代码放在生产程序集（可交付成果）中。

这条规则的原因很简单：测试代码可能会破坏您的现场安装。即使有良好的编码实践。即使有优秀的程序员。

测试代码的第二条规则：它必须由程序员自己维护：当开发人员重构他们的代码时，测试代码必须随之改变。因此，如果您可以以任何方式避免它，请不要将其放在单独的解决方案中。

从这里开始，你就靠自己了。就我个人而言，我更喜欢在我的生产程序集和我的测试程序集之间保持大约 1 对 1 的对应关系，将“.Test”附加到名称中。

然后，当我对生产程序集的 csproj 文件进行单元测试时，我会使用此命名将它们过滤掉。

哦，我有没有提到你永远不应该将测试代码放在生产程序集中？

score 1 · Accepted Answer

这个问题似乎有点主观，所以你可能会得到很多答案，最终由你决定什么对你和你的团队最有效。

我的 $.02 ...

我通常希望在与正在测试的代码不同的项目中看到测试。这可以防止生成的程序集变得臃肿，并避免必须将测试代码部署到生产中（或分发给客户端，具体取决于其目的）。

关于测试是否应该在同一个项目中，或者分布在多个项目中取决于正在编写的测试。如果测试都是相关的，并且将它们捆绑在一起是有意义的，那么将它们放在一个项目中，但如果它们完全不相关，那么我认为没有理由将它们放在同一个项目中。

我想这个判断可以像任何代码一样应用于测试。如果它在一起，就把它放在一起，如果没有，那就不要。

事实上，你正在编写测试，这意味着你可能走在正确的道路上，所以不要害怕尝试一段时间，确定它是否适合你，如果不适合，请尝试不同的方式。编写代码的美妙之处在于它可以随着时间的推移进行重构以更好地满足您的需求。:)

score 0 · Accepted Answer

这是我所看到的

a) 对于拥有独立管理测试代码的专门 QA 团队的大型团队，使用自己的解决方案管理测试代码会更容易。

b) 如果开发人员驱动单元测试和一些功能测试的团队不是那么大，那么将测试作为同一解决方案的一部分进行管理变得更加容易。

c) 如今，随着 TDD 被更积极地采用，将测试作为产品代码项目本身的一部分变得更加容易。

指导方针是把你的测试放在你认为最能管理它们的地方，对于今天的大多数人来说，它通常要么是 a 要么是 b。

3 回答 3