Visual Studio 解决方案的单元测试最佳实践
大家好，我的任务是在工作中重新构建我们的构建流程，我想开始将单元测试 (nUnit) 纳入我们的项目中。通过我的研究，我已经很好地掌握了我将使用的技术，但我想获得一些有关设置测试解决方案的最佳实践的建议，并确保我提出的解决方案是合理的。
我们的主要 VS 2008 解决方案大约有 4 个项目。对于每个项目，我将创建一个相应的单元测试项目并将它们添加到我们的解决方案中。我希望我们的开发人员开始开发这个解决方案，所有签入的代码都将返回到主干（使用 SVN）。对于我们的构建过程，我将使用持续集成服务器来构建和测试主干中的开发代码（带有单元测试）。只要正在构建，我就希望拥有一个包含我的 4 个项目和（但没有单元测试）的部署解决方案，并将该代码推送到 QA，例如 Test |分阶段然后最终生产。当我将代码推送到每个环境时，我的目标是不使用该代码推送单元测试项目。
从我的描述来看，这听起来像是一个典型的过程吗？如果是或否，这里有人有优化此流程的建议吗？
谢谢。
Hey all, I've been tasked to re-architect our build process here at work and I would like to start including unit testing (nUnit) to our projects. Through my research I've got a good grasp on the technology I'll be using, but I wanted to get some advice on best practices on setting up my solution for testing and to make sure my proposed solution is sound.
Our main VS 2008 Solution has about 4 projects. For each project I am going to create a corresponding unit test project and add them to our solution. I would like our developers to start developing off this solution, and all code checked in will go back to trunk (using SVN). For our build process, I will use a continuous integration server to build and test off of our development code in trunk (with the unit tests). As long as that is building, I want to have a deployment solution that has my 4 projects and (but no unit tests) and push that code for QA to, for example Test | Staging then ultimately Production. As I push code to each environment, my goal is to not have the unit test projects pushed with that code.
From my description, does this sound like a typical process? If yes or no does anyone here have suggestions to optimize this process?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
为什么会有两种不同的解决方案？只需使用包含单元测试的一种解决方案，然后仅选择生产项目的输出来发送到 QA/测试。 （或者，如果 QA/Test 收到完整的源代码，让他们仍然构建单元测试项目并忽略它们。）拥有多个解决方案听起来像是额外的努力却没有任何收获。
或者，如果您确实想要一个不带单元测试的构建，您可以有一个解决方案配置（如调试和发布），它只是不构建单元测试项目。在通常选择“调试”或“发布”的菜单中，选择“配置管理器...”，然后在下一个对话框中，单击“活动解决方案配置”下拉列表并选择“<新建>”创建一个新的。选择要复制的适当配置（可能是发布版），然后取消选中单元测试项目。
就我个人而言，我仍然会构建一切......
Why would you have two different solutions? Just use the one solution which includes the unit tests, and then select only the output of the production projects to ship to QA/Test. (Or if QA/Test receive full source code, let them still build the unit test projects and just ignore them.) Having multiple solutions sounds like extra effort for no gain.
Alternatively, if you really want a build with no unit tests, you could have one solution configuration (like Debug and Release) which just doesn't build the unit test projects. In the menu where you'd normally select Debug or Release, select "Configuration Manager..." and then in the next dialog, click the drop down for "Active solution configuration" and pick "< New >" to create a new one. Pick an appropriate configuration to copy from (probably Release) and then just untick the unit test projects.
Personally I'd still just build everything though...
就我个人而言，我不喜欢将测试与正在测试的代码分开。如果编写的代码确实可以进行单元测试，我发现最好将特定类的单元测试代码放在与类本身相同的文件中。这样，开发人员在向代码中引入更改或新功能时可以更轻松地跟踪单元测试。
然而，当需要考虑系统间依赖性时，单独的单元测试项目几乎是必要的。分离测试（集成而不是单元测试）提供了测试执行环境设置的自由度，并避免将不需要的代码引入到主代码库中。另一方面，您必须使用
[assemble:InternalsVisibleTo("test_assemble_name")]来启用测试代码来访问内部成员。条件编译可用于避免发布版本中的测试代码。尽管在某些特殊情况下，即使在发布版本中包含单元测试代码并使应用程序能够执行自测试也可能很有用。示例：使用语义契约声明接口，实现者必须向实现该接口的方法/属性/类提供特定属性。如果应用程序能够加载一些附加模块（编译时未知的程序集），自测试功能可能有助于确保整个系统正常工作。
Personally, I don't like splitting tests from the code being tested. If the code is written to be really unit-testable, I'm finding it better to have unit test code for a particular class in the same file as the class itself. This way it's simpler for the developers keep track of unit tests as they introduce changes or new features into the code.
However, separate unit testing projects are almost necessary when inter-system dependencies need to be taken into account. Separating tests (integration rather than unit tests) gives the freedom of test execution environment setup and avoids unwanted pieces of code to be introduced into the main code base. On the other hand, you'll have to use
[assembly:InternalsVisibleTo("test_assembly_name")]to enabled test code to access internal members.Conditional compilation can be used to avoid test code from release builds. Although, in some special scenarios, it might be useful to include unit test code even in a release build and enable the application to perform a self-test. Example: an interface is declared with a semantic contract that the implementor has to supply specific attributes to methods / properties / the class implementing the interface. In case the application is able to load some add-in modules (assemblies not known at compile-time), a self-testing capability may help ensuring the whole system will work.