Visual Studio解决方案的单元测试最佳实践

Question

嘿所有，我的任务是在工作中重新构建我们的构建过程，我想开始将单元测试（nUnit）包含到我们的项目中。通过我的研究，我对我将要使用的技术有了很好的把握，但是我想就建立我的测试解决方案的最佳实践提出一些建议，并确保我提出的解决方案是合理的。

我们的主要VS 2008解决方案有大约4个项目。对于每个项目，我将创建一个相应的单元测试项目并将它们添加到我们的解决方案中。我希望我们的开发人员开始开发此解决方案，并且所有签入的代码都将返回到trunk（使用SVN）。对于我们的构建过程，我将使用持续集成服务器来构建和测试我们在trunk中的开发代码（使用单元测试）。只要它正在构建，我想拥有一个包含我的4个项目和（但没有单元测试）的部署解决方案，并将该代码推送到QA，例如Test |分期然后最终生产。当我将代码推送到每个环境时，我的目标是不使用该代码推送单元测试项目。

根据我的描述，这听起来像是一个典型的过程吗？如果是或否，此处是否有人建议优化此流程？

感谢。

Answer 1

为什么你会有两种不同的解决方案？只需使用包含单元测试的一个解决方案，然后仅选择生产项目的输出以发送到QA / Test。 （或者如果QA / Test收到完整的源代码，让他们仍然构建单元测试项目并忽略它们。）拥有多个解决方案听起来像额外的努力，没有收获。

或者，如果您确实想要一个没有单元测试的构建，那么您可以使用一个解决方案配置（如Debug和Release），它不构建单元测试项目。在您通常选择Debug或Release的菜单中，选择“Configuration Manager ...”，然后在下一个对话框中，单击“Active solution configuration”下拉列表并选择“＆lt; New＆gt;”创建一个新的。选择一个适当的配置进行复制（可能是Release），然后解开单元测试项目。

我个人仍然只是建造一切......

Answer 2

就个人而言，我不喜欢从被测试的代码中拆分测试。如果代码编写为单元可测试的，我发现在类本身的同一文件中为特定类提供单元测试代码会更好。这样，开发人员可以更简单地跟踪单元测试，因为它们会在代码中引入更改或新功能。

但是，当需要考虑系统间依赖性时，几乎需要单独的单元测试项目。分离测试（集成而不是单元测试）可以自由地设置测试执行环境，并避免将不需要的代码片段引入主代码库。另一方面，您必须使用[assembly:InternalsVisibleTo("test_assembly_name")]启用测试代码才能访问内部成员。

条件编译可用于避免发布版本中的测试代码。尽管在某些特殊情况下，即使在发布版本中包含单元测试代码也可能很有用，并使应用程序能够执行自检。示例：使用语义契约声明接口，实现者必须为方法/属性/实现接口的类提供特定属性。如果应用程序能够加载一些加载项模块（编译时未知的程序集），自检功能可能有助于确保整个系统正常工作。