测试可以帮助项目团队找出代码中存在的问题,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。