.NET单元测试项目的组织

Question

49

你认为在管理大型 .net 应用程序中的单元测试时，最好的方式是什么？是为解决方案中的每个单独项目添加一个测试项目，还是使用一个包含所有项目中所有测试的大型测试项目？

例如，如果解决方案中有 10 个项目，是更好地添加 10 个额外的测试项目，还是一个大的测试项目就足够了？

我知道模块化测试程序集可以提供一些好处，但使用测试类别也可以实现类似的功能。使用多个项目会增加编译时间，但是您可以在不需要的情况下排除这些项目，而如果只有一个项目，则无法进行排除，但编译时间略微缩短。

请在您的答案中概述每种选择的优缺点。

- alxbrd

看看这个问题："最佳实践：组织单元测试"。虽然问题中的解决方案大小不同，但那里写的指南仍然有效。 - avivr

3个回答

10

就我个人而言，我更喜欢为每个真实项目创建一个专门的测试项目。当涉及到建立新功能/模块/项目时，我发现能够快速过滤掉其他不相关测试项目的套件要好得多。这样，在开发新项目时，能够快速运行测试，使TDD周期更快。

更重要的是，它可以帮助您维护您的各种测试/模拟类的良好组织，并根据需要整理您的固定装置，而无需将大量不相关的代码混在一起。对于新开发人员来说，找到相关测试的测试也更加容易。最后，它确保特定项目的测试依赖关系永远不会意外地依赖于另一个不相关的项目。

- Chris Sinclair

2

缩短反馈循环，加1分：通过不依赖无关事物来减少构建时间。 - Torbjörn Kalin

4

我的个人选择是每个项目都有一个测试项目，只包含单元测试。这个测试项目的文件夹结构与被测试的项目完全相同。此外，根据需要制作尽可能多的集成测试项目。

这种方法的主要优点是，当您想将1个项目用于不同的解决方案时，您总是会一起使用测试项目，以确保在新解决方案中进行更改时质量仍然保持。

到目前为止，我没有发现任何缺点，除了使用一个测试项目时需要更换引用的次数比使用多个测试项目时更多。

- amaters

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Huske · Accepted Answer

Phil Haack撰写了一篇关于单元测试结构的不错文章。这已经成为我编写单元测试时的个人最佳实践。以下是他的文章链接http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx

至于你的问题，我建议创建一个单独的项目用于单元测试，并将其命名为 .UnitTests（我这样做是为了区分单元测试和集成测试）。例如，如果我的主要项目是Sample.WebUI，则测试将为Sample.WebUI.UnitTests。

虽然单元测试确实会增加编译时间，但我认为这只是一个小问题。我正在开发一个有17个项目的解决方案（不包括单元测试），编译所有内容需要大约50-60秒。这正好足够让我把目光从监视器上移开，看看其他东西 :-)

关于测试分类，如果您有一些需要快速完成测试的每日构建，请使用它们并将其与需要更长时间才能完成的测试（如集成测试）进行区分。此外，如果您正在使用TFS，使用类别可以帮助自动化检查。