alx*_*brd 43 .net c# tdd nunit unit-testing
您认为在大型.net应用程序中管理单元测试的最佳方法是什么？是否更好地为解决方案中的每个单独项目添加测试项目,或者为其余项目中的所有测试添加一个大型测试项目？
例如,如果解决方案中有10个项目,那么有10个额外的测试项目或者一个大型测试项目是否足以满足整个解决方案的需要？
我知道模块化测试组件有一些好处,但使用测试类别可以实现非常相似的功能.许多项目的编译需要更长的时间,但您可以排除当时不需要的项目,而如果您只有一个项目,则无法执行此操作,但编译所需的时间会少一些.
请在答案中概述每个选项的优缺点.
Hus*_*vic 37
Phil Haack撰写了一篇关于单元测试结构的好文章.在编写单元测试时,这已成为我个人的最佳实践.以下是他的文章http://haacked.com/archive/2012/01/02/structuring-unit-tests.aspx的链接
至于你的问题,我总是为单元测试创建一个单独的项目,并用附加的.UnitTests命名它(我这样做是为了区分单元测试和集成测试).例如,如果我的主项目是Sample.WebUI,则测试将是Sample.WebUI.UnitTests.
确实,单元测试会为编译增加额外的时间,但我认为这是一个小问题.我正在研究一个包含17个项目的解决方案(不包括单元测试),编译所有内容大约需要50-60秒.只是有足够的时间把我的眼睛从显示器上移开并看一些其他的变化:-)
关于类别,如果您有一些日常构建需要快速完成测试,那么使用它们并将它们与那些需要更长时间才能完成的测试(如集成测试)区分开来.此外,如果您使用TFS,使用类别可以帮助自动化和测试您的签到.
就个人而言,我更喜欢每个真实项目都有一个专门的测试项目.在构建新功能/模块/项目时,我发现能够快速过滤掉其他不相关的测试项目套件要好得多.它使TDD周期变得更快,以便在我开发它时能够快速运行我的新项目的测试.
更重要的是,它可以帮助您根据需要为您的灯具保持各种测试/模拟类的良好组织,而不会将大量不相关的代码混杂在一起.它还使新开发人员更容易找到相关的测试.最后,它确保您的测试对特定项目的依赖性永远不会意外地依赖于另一个不相关的项目.