测试驱动实践

 

       WMS3.0的后台业务部分采用了测试驱动的开发方式。在开发过程中，对PBUnit做了一次比较大的升级，让测试变得更容易和稳固。

       在我们的TDD中，与标准的TDD还是有一些不同的，在此列出我们的TDD过程：

1)      设计，定义接口

2)      测试概要设计：在Excel中定义测试的场景、输入、输出、数据。此处的数据只定义主要的部分，对于与业务无关的，不定义。例如，序列号字段一般是不定义的

3)      测试详细设计：在PBUnit中将Excel中的数据维护进去。这里的数据必须定义完全。例如序列号必须定义

4)      编写业务类的框架代码（也可以第2步做）

5)      缩写测试类和测试代码

6)      运行测试，根据测试结果的指示编写业务代码，直到所有测试全部OK

 

       与标准TDD的区别：

1)      标准TDD中，先编写测试代码再编写业务代码。我们反过来的主要原因是如果不写业务框架代码，测试代码无法保存（在其它开发工具中，只是编译失败，不影响保存）。

2)      在标准TDD中，强调小步前进，代码是逐步完善的。而在我们的实践中，很多情况下是一次完成。因为在我们的设计中，已经把业务类分解得比较简单了，在测试设计的过程中，又充分考虑到了各种情况，所以业务代码往往是一次搞定。但与TDD的原则其实并不违背，如果情况复杂，我们也会小步前进，但我们不能为了“小步”而“小步”。

 

       在实践过程中，还发现需要注意：

1)      不能代替代码审查。测试是不可能穷尽所有情况的，在有些情况下，白盒仍然是必不可少的。

2)      开发人员要有正确的目标。在TDD中，开发完成的标准是通过测试。但这句话不能过死的去理解，我们的本质目标还是要正确的完成业务逻辑。开发人员需要了解需求、设计，测试文档能帮助你理解，但不能为了去凑测试结果而开发。

3)      不要先写业务代码，再写测试代码。理解了两步测试设计后，写业务代码的条件确实成熟了。但我们仍然不建议先写业务代码，因为测试代码是很简单的，业务代码往往比较复杂，应该先把简单的做完，然后全部投入复杂的部分，而不是很投入复杂的部分，然后单或会想到还有简单的没有做。