您认为在大型.net应用程序中管理单元测试的最佳方法是什么？是否更好地为解决方案中的每个单独项目添加测试项目，或者为其余项目中的所有测试添加一个大型测试项目？
例如，如果解决方案中有10个项目，那么最好还有10个额外的测试项目，或者一个大型测试项目是否足以满足整个解决方案的需要？
我知道模块化测试组件有一些好处，但使用测试类别可以实现非常相似的功能。许多项目的编译需要更长的时间，但您可以排除当时不需要的项目，而如果您只有一个项目，则无法执行此操作，但编译所需的时间会少一些。
请在答案中概述每个选项的优缺点。
答案 0 :(得分：35)
至于你的问题，我总是会为单元测试创建一个单独的项目，并使用附加的.UnitTests命名它（我这样做是为了区分单元测试和集成测试）。例如，如果我的主项目是Sample.WebUI，那么测试将是Sample.WebUI.UnitTests。
单元测试确实为编译增加了额外的时间，但我认为这是一个小问题。我正在研究一个包含17个项目的解决方案（不包括单元测试），编译所有内容大约需要50-60秒。只需要足够的时间将我的眼睛从显示器上移开并查看其他内容以进行更改： - ）
关于类别，如果您有一些日常构建需要快速完成测试，那么使用它们并将它们与那些需要更长时间才能完成的测试（如集成测试）区分开来。此外，如果您使用TFS，使用类别可以帮助自动化和测试您的签到。
答案 1 :(得分：8)
就个人而言，我更喜欢每个真实项目都有一个专门的测试项目。在构建新功能/模块/项目时，我发现能够快速过滤掉其他不相关的测试项目套件要好得多。它使TDD周期变得更快，以便在开发时能够快速运行我的新项目的测试。
更重要的是，它可以帮助您根据需要为您的灯具维护各种测试/模拟类的良好组织，而不会将大量不相关的代码混杂在一起。它还使新开发人员更容易找到相关的测试。最后，它确保您的测试对特定项目的依赖性永远不会意外地依赖于另一个不相关的项目。
答案 2 :(得分：3)
我个人的选择是每个项目只有一个测试项目，只进行单元测试。此测试项目的文件夹结构与正在测试的项目完全相同。除此之外，根据需要制作尽可能多的集成测试项目。
这种方法的主要优点是，当你想要一个项目并在另一个解决方案中使用它时，你总是将测试项目放在一起，确保当你必须在新解决方案中获得机会时质量仍然存在。
到目前为止，除了必须更换参考文献之外，我没有发现任何不足之处，而是在使用一个测试项目时必须这样做。
答案 3 :(得分：2)
看看这个问题："Best Practice: Organize Unit Tests"
虽然所讨论的解决方案大小不同，但在那里编写的指南仍然有效。