测试可以帮助项目团队找出代码中存在的问题，TDD方式更是将测试放在了开发工作的首位。那么在团队中该如何应用单元测试和TDD呢？开发者Paulo Ortins结合自身经历给出了本文中的12个经验教训。文章翻译如下。

　　背景

　　两年前，我在一个Web项目开发组中，项目的目标是编写一个类似Excel的、用来计算产品/服务价格的Web应用程序。项目团队被分成3部分——开发团队、需求团队和QA团队。随着项目越做越大，而我们没有使用任何形式的自动化测试（QA团队使用手工测试），结果导致项目的测试时间比开发时间还要多。每进行一次小的改动，QA团队都要花费几个小时来做测试。

　　有，我参加了一个开发者会议，并与其他程序员谈到了这些问题。他们建议我去学习单元测试、验收测试和TDD（Test-Driven Development，测试驱动开发）。

　　我的经验总结

　　下面是我在学习集成测试/TDD过程中的一些经验教训，希望能够对大家有所帮助。

　　1.  不要第一次在真实项目中尝试TDD

　　这可能会让你的项目很难进展。在采用TDD之前，你必须要了解TDD的工作流程以及如何去模拟对象（mock objects）、如何去模拟框架内部、如何组织测试等方面知识。因此，如果你的团队还没有准备好，采用TDD可能会拖慢你的项目，从而错过终交付期限。

　　2.  采用编程道场（Coding Dojo）方式学习TDD

　　我们发现编程道场是对新进入团队的开发者培训TDD以及提升他们编程技能的好的方式。

　　编程道场是一种帮助提高编程技能的训练方法。一般是在一个会议室里，有一台连接投影仪的电脑。每次道场还要有一个挑战题目。每次有两个人在电脑前结对编程来试图解决挑战的题目，并且由其他参加者提供建议。所有的参加者都要轮换到结对编程里进行演练。（来自维基百科）

　　3.  应用TDD之前尝试说服你的整个团队

　　没有什么比团队中存在“破坏者”角色更令人沮丧的了。如果团队中大部分人都在朝着TDD努力，而个别开发者所做的工作有可能毁掉这些努力，比如提交失败的测试代码等。我曾经与这类人一起工作过。在团队开始TDD开发之前，一定要让所有人明白它的好处，并了解如何测试可以使软件减少bug、如何重构代码而不用担心破坏整个项目等等。

　　4.  写足够多的测试

　　构建一个测试套件，等于构建了一个bug防护盾。当团队重构或改进软件时应该完全信任这个“盾”。如果这个盾有缺口，那么我们在更改代码时会增加引入未知bug的风险。不要强求测试套件覆盖的代码，这是不可能的，而且相当耗时，但是，覆盖大部分代码是完全可以实现的。一个好的准则是测试所有可能会出现问题的地方。

　　5.  使用覆盖率工具

　　覆盖率工具将会报告测试套件的缺口。借助这些工具，可以很容易识别哪些代码没有测试。这些工具可以给我们一个直观的认识，比如蓝/绿着色线表示正在测试中的代码，红色着色线表示没有测试。如果你是一个.NET程序员，Visual Studio旗舰版会带有这个功能；如果你是一个Java程序员，你可以使用EclEmma。