Bug Driven Development

     最近用java写了一个命令行大富翁的小程序。代码自然是是TDD出来的。测试这个东西，可能刚开始写的时候会觉得是多余的拖累，但是每次当你做了一些修改，运行所有测试发现某些测试废掉了，你就知道，之前的那些努力都不是白费。

     关于TDD的第二个D，初始提出来的含义自然是Development。但是后来很多人又把这个D做Design来理解。我觉得其实二者是反映了TDD过程中的不同侧面。当我写一个比较顶层的功能性测试的时候，我是描述了程序的外部特性。因此，当我让这个测试通过的时候，我是实现了功能，至于程序内部（或者说某个接口之下）是如何实现的，不得而知，这时的D，肯定是个Development；当我开始写单元级别的测试的时候，我其实就是在定义类的接口。定义接口也就是定义了类之间的互操作方式，其实也就是在做设计了。在这个阶段，说D是Design也是实至名归了。

     有点扯远了。今天要说的是BDD。嗯。。不是大名鼎鼎的Behavior Driven Development，而是Bug Driven Development。这里的D我就不敢说是Design了。这也就是为什么修bug这种事情让大多的程序员提不起兴趣。。为什么BDD呢？原因是：

• 从功能测试的角度来说，像大富翁这种以摇色子为基础的游戏的最大特点就是场景具有随机性，不可重复。当然我们可以对代码做一些侵入性的hack来做可重复的测试。不过为了测试去hack产品代码这种无所不用其极的做法，还是让我不大喜欢。。
• 不做功能测试，单元测试当然要写完备了。但是完备这种事情不是我说完备就完备的。很多分支不放到一个完成的场景中，只看一个小小的类的时候很难想得到，所谓“站的不高，看的不远”是也。想不到，自然不会写这样一个测试，不写测试，自然功能不会实现。
• 当然你在写单元测试的时候可以努力的去想想各种可能的分支，去尽量覆盖它。但是想起来还是太累。更重要的是，写了半天单元测试驱动出来一大堆组建，不拼起来运行，完全没有成就感。

     于是华丽丽的BDD出现了：

• 在写单元测试的时候只写出最容易想到的那几种分支，不花太多时间去考虑很边界的东西。
• 等到单元测试写的差不多了（也就是写出来的小组件已经可以支撑程序的运行了），赶紧装配起来看看。一运行，果然不出所料的各种bug，异常，甚至是错误。
• 通过简短的debug，找到问题所在，发现是某个组件的某个分支没有覆盖到，赶紧加个测试，实现之。当然以后这样的问题就不会再出现了。等到程序能够比较正常运行了，世界基本清净了。再接着写单元测试去。。。

     重复以上步骤，完成整个程序。

     这样写的好处在于，写起来没那么枯燥（不停的写但愿测试，加类，看不见成效）。另外让程序的运行帮你去寻找程序可能出错的那些边界情况，比自己使劲瞎想要快。