在团队中进行单元测试/TDD的12条经验

标签: 团队 单元测试 tdd | 发表时间:2013-07-11 10:37 | 作者:
出处:http://www.iteye.com

背景

两年前,我在一个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的风险。不要强求测试套件覆盖100%的代码,这是不可能的,而且相当耗时,但是,覆盖大部分代码是完全可以实现的。一个好的准则就是测试所有可能会出现问题的地方。

5.  使用覆盖率工具

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

6.  测试速度要快

当在构建软件时,我们永远都在追赶最后的交付期限。我们的测试应该帮助我们实现这一目标,而不是耗时和延迟。

如果写测试用例花费太长时间,在最后期限到来之前,团队可能不会再花时间写测试。如果在运行测试上花费太长时间,团队可能不会在每次更改代码后都运行它们。

7.  不要忽略失败的测试

如果你的团队对第1次失败的测试不在意,那么他们对第2、3、4次失败的测试也不会太在意。这种情况下,测试套件反馈的问题将会被忽略,测试也不会对软件质量有太大帮助。

8.  结对编程有助于团队应用TDD

当我们首次试图采用TDD时,或者最终交付期限临近时,我们可能会忘了写测试,而只顾写生产代码。结对编程可以阻止这种偷工减料的现象,强制团队成员编写测试。

9.  保持你的测试代码整洁

为了提高工作效率,我们的测试代码可能不会像生产代码一样整洁。由于软件发生改变时,测试代码也必须改变,测试代码也会越积越多,这样一来,会导致最终测试代码也很难维护。

10  测试应该有且只有一个失败的理由

这个理由就是发现bug。如果你的测试代码有大量的断言,你就需要小心。如果生产代码中的函数和类只有一个响应,那我们的测试代码也应该只测试这一个事件。通过这种方式,将很容易找出失败的测试,并弄清楚什么地方出问题了。

11.  编写单元测试将节省调试时间

通常在调试代码、寻找bug时会花费大量的时间,一旦你编写了单元测试,你将会在代码的每一块得到一个实时反馈,这将让你更容易找到bug,节省调试时间。

12.  持之以恒

应用TDD可以改变我们的心态。对于部分开发者而言,开始写测试很难,而在写生产代码之前写测试就更难了。重要的是,要持之以恒地写测试,一旦你的团队完全适应了这种方法,生产效率会成倍提升。

英文原文: 12 Lessons I learned using unit tests/TDD



感谢 wangguo 投递这篇资讯

已有 3 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [团队 单元测试 tdd] 推荐:

在团队中进行单元测试/TDD的12条经验

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

JavaScript TDD 神器jasmine

- - JavaScript - Web前端 - ITeye博客
今天参加了圣路易斯本地的一个meet up group. 演讲主题是javascript 的tdd. 演讲者展示了jasmine的功能,真的是神器啊. 以下是jasmine的网址:. jasmine的syntax 极其简单:. 还有很多功能还在探索中,在写2500行的js之前知道这个就好了. 已有 0 人发表留言,猛击->> 这里<<-参与讨论.

推行TDD的思考

- - 简单文本
目前来看,推行TDD的障碍大约有如下几点:. 分析需求并进行任务分解的能力; 3. 将测试作为开发起点的开发习惯; 4. 开发人员的重构能力,包括如何识别坏味道和如何运用重构手法; 5. 单元测试的基础设施,尤其是测试数据准备;. 开发人员对于软件质量,常常偏重于软件的外部质量,体现在他们的工作效益上,就是被测试人员发现的缺陷数.

Android单元测试

- - CSDN博客推荐文章
    单元测试不管对于初学编程还是已经工作了很久的开发者来说,都不乐意花时间去写认为没用的代码进行测试,只要交给测试人员就行了,虽然这样也能把软件改出来,但也许你要花上几倍的时间去修改问题,如果在开发的过程中花点时间去写单元测试代码,把尽可能出问题的地方都测试一遍,把问题扼杀在最开始的地方,这样你就不必为后来找问题出处而烦恼.

Hadoop之MapReduce单元测试

- - ITeye博客
通常情况下,我们需要用小数据集来单元测试我们写好的map函数和reduce函数. 而一般我们可以使用Mockito框架来模拟OutputCollector对象(Hadoop版本号小于0.20.0)和Context对象(大于等于0.20.0). 下面是一个简单的WordCount例子:(使用的是新API).

springboot单元测试技术

- - 海思
整个软件交付过程中,单元测试阶段是一个能够最早发现问题,并且可以重复回归问题的阶段,在单元测试阶段做的测试越充分,软件质量就越能得到保证. 具体的代码参照 示例项目 https://github.com/qihaiyan/springcamp/tree/master/spring-unit-test.

“单元测试要做多细?”

- - 酷壳 - CoolShell.cn
这篇文章主要来源是StackOverflow上的一个回答——“ How deep are your unit tests?”. 一个有13.8K的分的人( John Nolan)问了个关于TDD的问题,他说——. “TDD需要花时间写测试,而我们一般多少会写一些代码,而第一个测试是测试我的构造函数有没有把这个类的变量都设置对了,这会不会太过分了.

文章: Android中的单元测试

- - InfoQ cn
随着Agile的普及,以及开发人员对测试重要性的认识逐步加深,单元测试已经成了越来越多软件项目开发中不可缺少的一部分. 无论项目是不是采用TDD的形式来进行开发,单元测试都能够为项目的修改和重构提供一定的保障. 有奖参与:天翼伦敦会,上传应用,为中国队加油. QClub七月技术沙龙(太原/北京/上海/厦门/西安 7月21/28/29日 免费报名中.

迈出单元测试的第一步

- - 酷勤网-挖经验 [expanded by feedex.net]
单元测试不仅是软件行业的最佳实践,在敏捷方法的推动下,它也成为了可持续软件生产的支柱. 年度敏捷调查,70%的参与者会对他们的代码进行单元测试. 单元测试和其他敏捷实践密切相关,所以开始编写测试是组织向敏捷转型的踏脚石. 我将在本文介绍符合要求的小技巧,以及在开发周期里进行单元测试的步骤. 没有自动化,单元测试的习惯也不会持续太久.