初识 TDD

原文地址:https://geekplux.com/2014/03/21/understand_tdd (opens in a new tab)

最近团队进驻了 Innospace(一个创业孵化基地),感觉一切要走上正轨的节奏。每周 Innospace 会提供一些来自业内大牛的创业和技术方面的培训指导,活动也非常多。感谢我的实习团队,让我有机会可以学到更多的东西。今天的主题是 TDD(测试驱动开发),对我来说这个东西不仅是新鲜的,还是陌生的,所以我也是认真记了记,顺便整理成文。

维基百科上是这样说的:测试驱动开发(Test-driven development)是极限编程中倡导的程序开发方法,以其倡导先写测试程序,然后编码实现其功能得名。

好吧,上面那段翻译的真是让人捉急,人家原文是这样的:

Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.

看完英文应该比较好理解。通俗点就是:先写测试,再写只能让测试通过的代码,然后不停的循环这两个步骤,直到重构出满足需求的代码。以每个测试来推动整个开发的进行,这样有助于编写简洁和高质量的代码,并加速开发过程。

  1. 先写一个测试,覆盖的需求很少
  2. 检查是否运行失败
  3. 编写能通过这个测试的代码
  4. 运行该测试
  5. 如果测试通过,则写新的测试,覆盖更多需求;如果测试没有通过,则更改代码直到通过
  6. 重构代码,使其能通过新写的测试
  7. 重复第 5 步
  8. 重复第 6 步 ……

要实现前两点,则测试用例就不能涉及到文件、数据库、网络、环境(第三方类库)等。

TDD 作为一种敏捷开发方式,越来越为人所吹。毕竟敏捷开发越来越流行,所以 TDD 也是越来越被人吹捧。而且整个 TDD 开发过程看起来效果非常棒,尤其是在敏捷教练现场演示了一遍之后(果然例子理解起来永远比理论容易)。感觉是把大事化小,逐步解决。

不过,任何东西都有利有弊。比如,测试的范围就是个很麻烦的问题,怎么才能写出一个好的测试用例。既不会覆盖的需求太多,又不会覆盖的太少……

不管怎样,还是学到了东西,非常感谢两位敏捷教练。