美文网首页软件测试TDD(测试驱动开发)
我的TDD感悟(三)--TDD的“绿”

我的TDD感悟(三)--TDD的“绿”

作者: 人在云中 | 来源:发表于2018-12-10 11:27 被阅读10次

    在我的TDD感悟(二)中,说到了一个TDD的周期不宜太长。不管是红,绿还是重构。每个步骤的步伐小一些会更可控,出现问题定位也更快。那么在“绿”的阶段我们需要注意些什么呢?

    速度要快

    在这一步里,初学者最容易出现的问题是长时间呆在这个“绿”的环节中,直到一口气完成所需的编码。然后有些人看到是绿的状态,就觉得事情做完了,开始做下一个用例了。如果是红的状态,那就不停的测试,直到绿的状态出现为止。

    这种方式的缺点在于:

    • 没有后续的重构步骤,代码容易越写越大,不容易定位Bug
    • 不考虑代码的可维护性和可扩展性
    • 如果在过了一段比较长的时间后,实现了用例,然后再转到重构环节,可能这个时候需要重构的代码量变的比较大了,这个时候重构的工作就变得不是那么的容易了。很多人就会选择跳过重构这一步

    因此,“绿”这一步的要点在于:

    • 步伐要小,甚至一开始为了验证测试代码是否ok,可以直接类似return 1; 这种简单的方式,先让状态变为“绿”。
    • 如果状态由“绿” -> “红”,那么这种情况必将容易出现在这次的改动里。一次的改动如果是在2~3分钟,代码量不会很多。这个时候通读下代码, 也是会比较容易发现问题,减少了断点调试的次数

    实现算法

    “绿”的环节中,重要是快速,小步快跑实现功能代码。这个时候代码质量不是首要考虑的事情。所以这个阶段往往会出现一些临时代码,或者写死常量等。这些问题都会在重构的环节中消灭掉。目的只有一个就是:

    重构和实现算法是在不同的步骤里

    把“绿”和“重构”分开, 更有利于大脑串行工作。也让自己更主动的重构,改进代码质量

    • 如果不需要重构,那就跳到下一个循环,继续 “红” -> “绿” -> “重构”之旅
    • 如果需要重构,那么在现有的代码上,考虑消除重复,提高可读性,提高可扩展性。这个在每个小步骤里来做,让重构的代码量不至于那么大。提高重构的效率,提高代码修改引入bug的修改速度。

    最后,对TDD非常熟练后, 可以适当延长“绿”这个过程的时间。比如3~5分钟,但也不要太长,否则还是容易出现上述的一些问题。

    坚持小步快跑,我们能得到更多

    相关文章

      网友评论

      • 武可:对TDD非常熟练后,会不假思索的测试。要求他延长可能会不适应吧。:smile:

      本文标题:我的TDD感悟(三)--TDD的“绿”

      本文链接:https://www.haomeiwen.com/subject/fqtrhqtx.html