测试驱动威力不分国界

最近公司开始了一个新项目，在国外成立了一个开发组5个人

老板想让他们使用TDD来进行开发（Unit Test），于是我和另两个中国同事就应招过去了两个星期（主要是TDD，当然还顺带处理点别的事情）。

在这两星期时间里 我们把它主要分成了两部分 1.介绍TDD 2.手把手实验

在介绍TDD的阶段 我主要讲了TDD原理，我们中国组导入TDD的过程和导入前后的体验，老外听得还是很感兴趣的。

在手把手实验的开始阶段 我们是在一起用TDD实现了一些测试代码和production代码，在实现代码过程中 发现有个class很难测。

首先我们想到的当然是用Typemock, 那可是相当强大的测试工具，再烂的设计代码也可以是可以测试的（这次设计我们中国没有参与，所以设计不是非常的支持测试），当时在用Typemock进行测试时 我们发现测试代码那是相当的复杂，大大超过了真正的Production代码。

这是老外们对TDD失去了信心，觉得这东西太浪费时间了，大部分时间都在想怎么测，写测试代码，production代码嘛 其实很简单，只是一点点逻辑和对第三方库的调用。

就在我们纠结的时候，我同行的有个中国的同事提醒了我，是不是设计上有问题？这句话直接带来了革命的效果，把我们从埋头出馊点子解决问题的状态拉了回来 去思考问题的本质。后来我们讨论之后发现 这个类的责任太多了，不是高内聚的设计。经过一番讨论我们决定把功能拆分成“小的”“多个”“高内聚”的类来实现，做成Compsite的设计。奇迹发生了，测试变得比开始容易多了。

由于类的切得责任很小很清楚，我们于是就分成了两个小组同步工作，一个组负责service部分，一个组负责PLC部分的实现，也是按不同的层进行实现。

有些细节在两个组做代码实现时 是非常有意思的： *大家首先作为团队思考该怎么写测试代码 *当test case运行失败时，团队思考原因然后讨论该怎么实现代码 *单test case过掉，变成绿色时，大家都会很激动，高呼“Yeah!!”.

我深刻记得有一天项目经理 走进我们的会议室 说“我感觉你们现在的状态非常好，你们这种团队的工作状态非常的让我惊讶！”

4天之后 奇迹再次出现，当我们把两组的代码合起来做集成，然后做功能测试时，发现系统功能运行如预期的，而且粗略的测试是没有bug的。我们都觉得很开心，也觉得TDD真的很可怕，因为在用TDD以前，做集成测试时，总是会bug一堆。

另外要提到的是在去国外之前我刚好参加了一个Srum的聚会，其中强调说每个Sprint最好有可交付的产品。这次TDD培训我们也用到了这个，我们从各个层都挑了一些class做实现，目的是能搞出来一个可运行的系统，即使只有很少的一部分功能。

在离开前老板和我们聊了聊这次培训的效果，那可是绝对的高评价，看起来所有的利益相关方都很满意。我也开心的离开了，带着好心情去德国逛了一把~~

收获：

如果发现测试很难做时，不妨换个角度看看设计是否可以优化或改进。

每个迭代最好能出一个可运行的系统，这样客户和开发人员都很兴奋。

团队的力量是很可怕的。