解读微服务下的契约测试——看微服务如何完整应用系统验证之道( 四 )


为了保证编译通过,编写一个Calculator类,代码如下 。

解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
然后运行测试,出现空指针异常,原因是变量calculator为空,再次增加代码来解决空指针的问题,测试代码改造如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
再次运行测试,运行正常,但测试结果失败,报错如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
显然期望结果是2,但实际得到的结果是0,快速修改代码来尝试让测试通过,修改add方法,代码如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
再次运行测试,测试成功,不过还需要编写新的测试来让测试失败,添加测试如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
再次运行测试,不出意外测试再次失败,错误如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
这时继续重构我们的实现,代码如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
再次运行测试,测试通过,我们还需要再次增加测试代码来查看这次的实现逻辑是否有问题,代码如下 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
再次运行测试,测试依然通过 。如果不放心,可以继续增加一些其他条件的输入参数,尽量是一些边界值或不同的情况组合,如果此时测试仍然能够通过,基本上就算完成了该功能的开发 。
这就是通过TDD的方式开发一个功能的过程,虽然这个场景比较简单,但已经演示了TDD的精髓所在 。有时我们在所有测试通过后,可能还会加入一些重构代码的环节 。例如,在测试通过的过程中,会产生一些“坏味道”的代码,带来如代码冗余、复杂度过高、信息链等问题,这时我们就需要进行重构,重构会出现新的问题,导致测试再次失败 。有测试保障代码的逻辑,我们就可以进行放心大胆的重构,继续TDD让测试再次通过 。综上所述,从TDD的过程可以得出如图4.4的流程 。
解读微服务下的契约测试——看微服务如何完整应用系统验证之道

文章插图
 
从图4.4可以看出,在TDD的过程中,实现功能之前需先编写会失败的测试,然后以最少的代价编写具体的实现代码让测试通过,在测试通过后,再对代码进行重构,测试可能失败,或者再次尝试编写一些会失败的测试,再继续整个过程 。

【解读微服务下的契约测试——看微服务如何完整应用系统验证之道】


推荐阅读