迈出单元测试的第一步(2)

　　评审：为了增加测试成功通过的机会，编写第一个测试时我们应该和同事结对。两个人都能从实践中学习，而且我们还能立即评审测试。最好对所测的内容、测试的名称达成共识，因为这会成为团队其他人员的基本模板。

　　AAA：现代测试的结构符合AAA模式——Arrange(测试设置)、Act(调用测试里的代码)、Assert(测试通过的标准)。如果我们使用测试驱动开发(TDD)，我们要先编写完整的测试，然后再添加代码。对遗留代码来说，我们可能需要换一种方式。一旦我们有一个场景和名称需要测试，那先编写Act和Assert部分。我们要不停构建Arrange部分，因为对需要准备或仿造的依赖关系，我们知道的要更多一些。然后继续这么做，直到有一个测试能够通过。

　　重构：一旦准备好了测试，我们就可以重构代码了。重构和测试都是后天获得的技能。我们不仅要重构被测试代码，也要重构测试本身。但DRY(不要重复自己)原则不适用于测试。测试失败时，我们希望尽快修复问题，所有的测试代码最好在一个地方，而不是分散在不同的文件里。

　　可读性：测试应该是可读的，最好是人类可读。和搭档评审测试代码，看他能否理解测试的目的。评审其他测试，看看它们的名称和内容怎样与相邻的测试区分开来。一旦测试失败，就需要修复它们，最好还是在运行失败之前评审它们。

　　组织：一旦我们有了更多的测试，组织就有了用武之地。测试可以在很多方面有所不同，但最明显的一个就是如何快速运行。有些测试可能在毫秒内运行完，而有些则需要数秒或好几分钟。和工作一样，我们都希望得到最快的反馈。这就是前面谈到的怎么按一定的节奏去进行。要做到这一点，你应该把测试划分一下，把快的测试和慢的测试分开运行。这能手工(努力)去做，但在.NET领域，Typemock Isolator有一个运行器，能自动按运行速度分离。

　　总结

　　迈出单元测试的第一步是很有挑战的。体验依赖的东西很多——语言、工具、现有代码、依赖关系和技能。只要稍稍思考，进行大量训练和实践，你就能渐入测试的佳境。

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