qileilove

blog已经转移至github,大家请访问 http://qaseven.github.io/

解读TDD的五大误区

 摘要:所谓TDD简单地说就是以下两个步骤:确保所有的需求都能被照顾到;在代码不断增加和重构的过程中,可以检查所有的功能是否正确。本文我们一起来看下关于TDD的五大误区。

  TDD(全称Test Driven Development)测试驱动开发,是一种软件开发的流程,其由敏捷的“极限编程”引入。其开发过程是从功能需求的测试用例开始,先添加一个测试用例,然后运行所有的测试用例看看有没有问题,再实现测试用例所要测试的功能,然后再运行测试用例,查看是否有case失败,然后重构代码,再重复以上步骤。

  其理念主要是确保两件事:

  ● 确保所有的需求都能被照顾到。

  ● 在代码不断增加和重构的过程中,可以检查所有的功能是否正确。

  原文作者Adam Bar在拜读了Bradley Braithwaite的文章后引发了一些思考,对此,他补充了对TDD的一些看法,列举出TDD的五大误区。以下是文章译文:

  1、即使没有单元测试,也比有单元测试做的差要好。 (It's better to have no unit tests than to have unit tests done badly )

  2、利用代码测试能够产生许多高效的代码且代码看起来更加可靠、实用。

  一、不要使用Mocking Framework VS 太多测试设置

  也许有人会说,这两点很矛盾,因为使用Mocking Framework会导致产生过多的测试设置。这就需要我们保持一个良好的平衡问题。

  测试代码势必会产生一些依赖关系,倘若不使用Mocking framework,那么我们将无法进行单元测试。这一点是肯定的。

  这里例举有关代码测试和数据库的例子——我们通常称之为集成测试、half-arsed测试,这也是测试查询本身唯一可靠的方法。

  但是,在大多数情况下,我们使用stubs,避免使用mocks——两者之前的区别非常重要。Mocks作为一种行为测试工具常被用来执行检查过度使用的自定义测试,同一个人在同一时间编写代码,就如同检查我们刚刚故意创建的设计一样。 TDD导致大量的Mock和Stub。Test Case并不一定是那么容易的,如果你的Test Case中的Mock可能是错的,你需要重写他们。也许你会说,就算是不用TDD,在正常的开发过程中,我们的确需要使用Mock和Stub。没错!的确是这样的,不过,记住,我们是在实现代码后来决定什么地方放一个Mock或Stub,而不是在代码实现前干这个事的。所以,TDD中,Test Case是开发中最重要的环节,Test Case的质量的问题会直接导致软件开发的正确和效率。

  我们更加关注的是真实的验证结果(stubs将带给你很多帮助),而不是通过耦合来实现。 没有什么比维持一个测试套件和spaghetti-flavoured mock 装置更糟糕的事了。

  二、主张太多元素

  在每次测试时主张有一个逻辑是很好的规则。即使它意味着调用几个Assert,但对我来说,使用任何asserts 都是同等重要。

  三、追溯编写测试

  大多数TDD的获益方式,从实施前就可进行思考。比如: 写测试需要成本,测试需要维护。

  许多开发者认为这不仅这是通往幸福的路径,还有关于负面的情况及边界值(boundary values )。  此外,它还强烈支持KISS和YAGNI原则,这对于长期代码库来说非常重要。

  我个人比较喜欢使用TDD来配合检测错误报告。通过重新创建失败条件来编写失败的单元测试使得更容易,这将有助于隔离故障,分析根本原因所在,这往往比在现实生活的情况下重现 bug容易得多。追溯编写测试只适用于集成测试中查找Bug。

  四、测试过多代码

  这是一条放之四海而皆准的普遍真理。

  在利用单元测试核心代码中我看到许多有价值部分。创建这些代码我更多的是根据TDD原则创建而来(尤其是没有产生错误的代码及没有失败的测试)。

  但是我并不把100% 的代码覆盖率作为最终目标,因为这样没有任何意义。

  我想,总会有相当多的代码不只是适用于单元测试,即协调/组织类型的代码(我们称之为组成节点将其作为组成root的引用),它们需要一些依赖关系,通过调用几种方法,把代码从这里移植到那里,无需添加任何逻辑,而无需真正干扰数据。

  由于其沉重的mocks和stubs 的使用,这种编写测试的代码比代码本身要复杂的多。Bradley的经验法则对我来说:为每一个IF, And,Or,Case,For,While条件语句编写一个单独的测试,当所有分支/条件语句被覆盖时,该代码将会被完全覆盖。

  五、TDD跟测试的关系

  测试是TDD的必然结果。如果团队一直在实践TDD,所有的代码都会有相应的测试,所有的测试其实就是整个系统的脚手架。 TDD方式的开发是从写测试开始的。

  使用TDD时,功能开发总是实现沟通结束条件,也就是在何种情况下,可以认为功能完成,这个结束条件是以测试体现的。

  实践TDD时,写代码只有两种目的:1、让一个失败的测试通过。2、在不添加新功能(也就是不需要添加新的测试)的前提下,让代码、结构或者测试更加清晰、整洁、易懂。

  对于需求来说,TDD更能引导开发人员做出真正符合需求的东西,不会过渡开发。对于设计来说,TDD的实践能帮你清理思路,但不能教会你做好的设计。对于质量来说,TDD保证所有的代码都有测试覆盖,肯定能提高质量。

  写在最后:

  对此,有专家建议想要用TDD请首先学会测试的基本功,另外要养成没有测试过的功能坚决不算结束的功能的习惯,这个习惯很重要。为什么TDD狂热者能够report出极少数量的bug的原因之一,就是养成经常性测试的习惯。

  使用 TDD 的目的是高效的开发高品质的程序。如果发现 TDD 危及这个目标(没有完美的开发模式,TDD也有自身的弱点和局限),那么请适当的妥协。

posted on 2013-02-17 11:32 顺其自然EVO 阅读(179) 评论(0)  编辑  收藏 所属分类: 测试学习专栏


只有注册用户登录后才能发表评论。


网站导航:
 
<2013年2月>
272829303112
3456789
10111213141516
17181920212223
242526272812
3456789

导航

统计

常用链接

留言簿(55)

随笔分类

随笔档案

文章分类

文章档案

搜索

最新评论

阅读排行榜

评论排行榜