tdd(测试驱动开发)的概述

最近的工作的项目,使用了tdd(test-driven development测试驱动开发)的开发模式。
这两几年大概听说了无数种xxx-dd, ddd, tdd, atdd, bdd, fdd, udd各种名词眼花缭乱,当然很多dd其实也有相互借鉴(抄袭)的部分。不过仔细想来测试驱动应该也是很久以前就有的一种技术了,21世纪早已经是测试自动化的年代。tdd讲师还推荐了有一本书叫《XUnit Test Patterns: Refactoring Test Code》。书早在2007年就出版了,自己也算是后知后觉。

接触tdd之前的想法。

代码只要写的漂亮就行了。代码写得漂亮了,看代码就全懂了,文档的什么都是垃圾!
代码写得好,可读性强,造成问题的概率就会低。
程序设计是很重要的,如果不做设计就开写,结果就是产生一坨垃圾!所以不要急着去写代码,写做好设计,理清思路后再动手!
突然有一天以为tdd教洗脑能手出现,提出了令人毁三观的观点----不要在写代码之前去做设计!
什么?!为什么会这样?!
展开之前,先简单介绍一下tdd的方法论

tdd的步骤

tdd(测试驱动开发)的概述_第1张图片

1. 先写测试代码,并执行,得到失败结果

比如我们要写实现一个功能,当输入值大于等于0时返回true,当输入值小于0时返回false。
按照tdd的步骤先要写一个肯定会失败的测试,注意测试代码先于实现代码,因为还没有实现代码,所以测试必定是失败的。
大概是下面这种样子。

  • 测试代码
@Test
void greaterEqualThan0Test{
  // given 
  int input = 2;
  // when
  boolean result = greaterEqualThan0(input);
  // then
  assertThat(result, equalTo(true));
}
  • 实现代码(未完成)
public boolean greaterEqualThan0(int input){
  return false;
}

运行测试,得到红灯。

2. 写实现代码让测试通过

先不管任何设计啥的,只要让测试过了就行,随便乱写。比如下面的的代码。

  • 实现代码
public boolean greaterEqualThan0(int input){
  return true;  // 我勒个*这都可以!?
}

运行测试,得到绿灯。

3. 重构代码,并保证测试通过。

实现太简单。没什么能重构的,跳过。

4. 反复实行这个步骤 测试失败 -> 测试成功 -> 重构

再写一个测试

@Test
void greaterEqualThan0Test_2{
  // given 
  int input = -1;
  // when
  boolean result = greaterEqualThan0(input);
  // then
  assertThat(result, equalTo(false));
}

执行测试,失败。
写实现。

  • 实现代码(重构前)
public boolean greaterEqualThan0(int input){
  if(input >= 0){
    return true;
  }
  return false;
}

重构
因为有了自动测试的保护,你可以尽情地修改之前看得不爽的代码,为所欲为。
其结果可能是下面的情况。

  • 实现代码(重构后)
public boolean greaterEqualThan0(int input){
  return intput >= 0;
}

当然我们还可以把测试代码也重构一下。

  • 测试代码
@ParameterizedTest
@CsvSource({"2, true",
            "-1, false"
  })
void greaterEqualThan0Test(int input, boolean expectedResult){
  // given 

  // when
  boolean result = greaterEqualThan0(input);
  // then
  assertThat(result, equalTo(expectedResult));
}

之后也可以多加case

  • 测试代码
@ParameterizedTest
@CsvSource({"2,  true",
            "-1, false",
            "0,  true"
  })
void greaterEqualThan0Test(int input, boolean expectedResult){
  // given 

  // when
  boolean result = greaterEqualThan0(input);
  // then
  assertThat(result, equalTo(expectedResult));
}

这种小学生都能完成的代码,可能给人杀鸡焉用牛刀的感觉。不过相信能给大家一种比较直观的印象。
需要注意一点,就是在第一步写测试代码的时候,一定要运行测试,确认测试是失败的。我觉得有两个目的。

  • 思考你应该如何验证你的程序,帮助你写出一种比较容易验证的代码。
  • 防止测试本身是错误的。
    比如,你可能一不小心手滑写了下面一个测试。
// given 
int input = 2;
// when
boolean result = greaterEqualThan0(input);
// then
assertThat(true, equalTo(true));

这个测试是没有任何意义的,对你的代码重构起不到任何保护的作用。

另外请注意!本人在写实现大码之前没有做设计!!!,虽然很有造作的嫌疑。。。

tdd的思想(个人观点)

首先声明一下这些只代表本人的观点,主要来自于工作与上一些tdd教徒的交流体会。我不是很确定tdd是否有这样系统的原理。

1. 测试代码先于实现代码,不允许有没有测试代码的实现代码。

这个字面意思还是很好理解。在这样的开发方式中,你所开发的功能绝对会被测试保护的。
如下图。
tdd(测试驱动开发)的概述_第2张图片
而下面这种情况是tdd所希望避免的。实现的代码的范围超出了测试代码。而超出的部分没有受到测试的保护,是容易产生bug的部分。
tdd(测试驱动开发)的概述_第3张图片
有一些开发者可能喜欢先写代码,后写测试。从tdd的角度来说,这样何容易造成上图的结果。因为当你的实现代码变复杂了之后,你可能遗漏一些测试的case。
另外,先开发后测试的另一个缺点是写测试的难度会变高。这应该也很好理解,当你设计程序时,如果你没有考虑可测试性的要素,很可能最终的代码会变得超难测。比如一个没有返回值,但有副作用的函数,写测试就会比较麻烦。(当然我不是说写函数一定要有返回值 (´ε`;))

2. 好的设计是不断的重构中实现的,想要在写代码前就作出好的设计是很有难度的。与其在最初去做好的设计,不如不断的重构,使代码进化。

其实这个思想应该是Emergent Design。本身和tdd并无直接关系。但由于培训师讲师非常提倡这个思想,结果不慎被洗脑,在这里讲一下。
这个思想的缘由大致是,程序用来实现具体的业务逻辑,当这也业务逻辑是复杂的情况下,理解业务逻辑是需要花费时间的。
当程序员开始开发,处于程序设计阶段时,对业务地理解是相对少和浅的。对业务的理解是随着开发的推进而增加。
tdd(测试驱动开发)的概述_第4张图片
这种情况特别在维护现有产品时更容易显现。(一个原本已经能够运行的成品,因为一些功能的修改或增加,突然一些地方就跑不了了。。。仔细一查,发现了一些不为人知的业物逻辑。。。orz)
当你在对业务的理解相对少的前期阶段,做出好的设计是很困难的。而在开发有一定进展后,对业务有了更好的理解,这时候做出的设计就会更符合需求更加合理。
另外ttd(也不一定源于tdd)把产品品质分成两种。

  1. 外部品质: 保证程序根据需求运行,不出错
  2. 内部品质: 产品的设计,可维护性等
    tdd(测试驱动开发)的概述_第5张图片
    外部品质是通过测试来保证。而内部品质则是通过重构来实现更好的设计。、

3. 不做过度的设计(over engineering)

这个观点其实和Emergent Design也是关联的。程序开发的前期阶段为了程序更好的扩展性,往往做了一些超越目前需求的设计。貌似是有数据支持,不过因为本人太懒,懒得找。维基百科上说是,这些为了扩展性所做的设计,最终得到使用的不足10%,所以90%的时间都会被浪费。
另外具有扩展型的设计,因为这些设计的部分很可能现阶段没有被使用,反而会迷惑其他的开发者。(比如你设计了一张数据表,然后为了将来不对数据表做更改,加了一列 colum_for_future_extension)
对此还有一个标语专门提倡这种观点。YAGNI。You ain’t gonna need it!
所以tdd所期望的是程序的实现能与现阶段的需求完全契合,不做过度的设计。你要做的是根据现在的需求写测试,让测试通过,并此需求上把代码设计的更好更合理。因为测试为先,测试又根据需求来写。这样的话会比较难产生over engineering。

一些推荐的实践方法(best practices)

根据上面介绍的思想,tdd还有有一些推荐的实践方法。

1. baby step

tdd希望程序员开发时,频繁地实行这个开发循环。
tests failed -> tests passed -> refactoring
不要写了半小时测试,然后运行一下,然后又开发半小时。
频繁地运行测试,来验证自己的实现或者对业务的理解是否正确。步步为营,循序渐进。如果测试出错了,回退到之前测试通过的状态也比较容易。

2. 不同时做两件事情

tdd的开发步骤分为,tests failed, tests passed, refactoring,每个步骤只做这个步骤该做的事情。
比如在test passed的步骤里,你要做的就是让测试尽快通过,而不是一边想着让测试通过,一遍还要重构。结果在测试还没通过的情况下就先重构,结果就是那个步骤出了错就比较难判断。
类似地,在写失败测试时,不要就急着把业务逻辑给实现了。

3. 通过发现code smell来改进代码

好的代码是很难描述的,而且众说纷纭。不过什么代码是不好的,倒是有一定共识,并且容易具体化的东西。
比如一个方法写得太长了,很有可能需要把这个方法拆分成几个抽象度更高的方法。
不好的代码有一个专门的术语,code smell(代码发臭了。。。)。在此引用一下维基百科。
code smell
在tdd的第二步让测试通过后,第三步refactoring,code smell便能帮助你发现需要refactoring的地方。

结语

刚受到tdd教洗脑时,感觉这种理论根本就是毁灭性的,反智的!有点像达尔文的《进化论》。《进化论》之前人们普遍接受神创思想。多样与复杂的生物,只有神能够来创造。而《进化论》认为,不需要神的帮助,生物也能自主从简单演化到复杂,从单细胞演到多细胞。如果很极端地去遵循tdd的教义(我的例子中其实也没有严格遵循啦 ^ ^ ),那在编程时不用作任何设计,不断通过重构来演化,最终得到的会是高品质的程序。
不过我最终还是入教了。。。那么tdd就是是不是个神器?之后的文章想谈谈在实践tdd时遇到的问题与感想。

你可能感兴趣的:(tdd(测试驱动开发)的概述)