软件测试3：聊聊纠结的TDD

辛昕

软件测试3：聊聊纠结的TDD [复制链接]

      前面我提到一个可能在座都很陌生的名词：TDD，测试驱动开发 test driver develop.

      我虚心接受freebsder的意见，不纠结。
      尽量说的简单点，不要让 玲珑妹子 都没心情看～～

      所谓 测试驱动开发，往简单了说就是，它把测试的执行时间和意义往前提了一大截，同时也赋予了它更加大的意义或者说作用。
      如我们大多数人的常识所理解：测试这个东西，不管是为了发现软件里的错误，或者是为了验证软件没错。它都是应该在 软件已经生成了以后才有讨论意义的。
      而TDD里，它最与众不同之处在于：测试（用例的定义和构建）居然先行于 开发本身。这体现了它的一个本质上的对测试的颠覆性理解：它把测试解释成一种定义软件行为和功能的工具；

      关于这个话题，有很多书（一般提到 极限编程 原型迭代一类的书都或多或少会提到这种测试思维），这里我推荐一本我手头在看的书，这本书的另一个特别适合我们的地方是，这是一本针对 单片机/嵌入式 C编程 领域的 TDD著作。

      《测试驱动的嵌入式C语言开发》 James w Grenning著 尹哲等译

       这本书中介绍了一个很小很简单的 C语言自动测试框架 Unity （注意区分，它和那个大名鼎鼎的3D游戏库 一分钱关系也没）
       通过这本书中的例子，我们可以理解 TDD的一些思想和操作方法。

       它操作起来，最显著的地方就是 所谓的微循环。

        比如仅仅只是做一个16个LED的流水灯，整个过程可能只有十几二十分钟，他的微循环却是以几分钟为单位来执行的。
        
        1.先写测试，这个测试定义了下一步要做的事，比如让LED在不同状态下按照指定的亮灭组合表达.....
        2.运行测试，必然通不过；
        3.花几分钟就完成了这个功能；
        4.再运行测试，通过就完成，不通过就继续重复 3，4；

        这本书天花乱坠地鼓吹了很多这样做的好处，如模块功能的纯粹性，很多细节的问题会在很早的时候发现、以及模块间的可测试性大大提高 等等等等，它们听起来确实很有道理。这也是我当初刚接触这个概念时，被它一下鼓动了的原因。

        但接下去，我们试图把这些测试思路或者说开发思路用在自己的实际开发中的时候，就会发现，这个东西没有什么可操作性，而且粒度很难把握。
      
        待续～ 接下去我会试图尽可能简单地用例子来描述这些小步骤开发-测试的具体过程，并说明它为什么难以实际操作。
        同时，关于粒度的讨论，还有前面一直提到的要把测试分两大类来看待，这些问题的答案都可以从TDD这个测试思想去说。
        

     

soso

看辛昕的文章比以前精简多啦，看来may妹子和free哥的魅力就是大呀 。

加油加油