自动化单元测试建议

本文只是一些您在创建单元测试时可以采纳的基本建议。

设计彼此独立的单元测试，其中它们可以独立运行（由于可以通过测试 UI 随意选择或取消选定它们）。

不要只进行正面测试。请确保代码能够响应任何方案，包括发生意外时（资源不可用，数据库只读等）。

把自己当作一个 QA 人员，想象成一个测试人员，而不仅仅是一个开发人员。您花在设计单元测试上的时间将有助于减少日后解决故障所用的时间。请注意对象的几个小细节：数据如何在对象之间传输？谁使用它们？销毁对象容易吗？如果我“进行此操作”，将会发生什么？

跳出您自己的思维模式。尽可能多地对测试进行头脑风暴。当您完成时，回头查看您可能漏掉的内容。来自团队成员的请求反馈 — 例如，他们创建了什么其他类型的测试？其他人可能提供一个对熟悉自己代码的开发人员而言非常困难的观点。

代码覆盖。使用 VSTS 代码覆盖规范提供有关每个测试运行中实际执行多少代码的信息（代码的行数，占所有代码的百分比）。如果编码完成，并且通过了所有测试，但代码覆盖显示只执行了该逻辑的一小部分，那么您的测试真的成功了吗？高代码覆盖不一定意味着您具有一个完整的“测试”集，而未覆盖的代码通常非常适用于一个新的测试用例。

当生成单元测试时，要帮助其他人了解您的代码：

使用一个项目结构，该结构映射所测试程序集的结构。

每个程序集有一个相关的测试程序集。

每个类有一个相关的测试类。

在各自的测试方法中包含每个方法名（即，Load() 将有 PositiveLoadTest()、NegativeLoadTest()、PositiveScalarLoadTest() 等的测试方法）。

使用一致的命名协定，包括对象的属性和方法名。

此外，当其他所有测试都失败时，请进行调试。自动化单元测试应该有助于减少您用在调试器上的时间。但是，如果测试结果和代码覆盖无法提供测试失败的原因，那么您大可不必担心调试单元测试。从 Beta 2 版的 Visual Studio 2005 Team System 开始，开发人员可以使用 Test Manager 中的 Debug checked tests 选项调试他们的单元测试程序集。

原文转自：http://www.ltesting.net