如何坚持TDD──使用者出现的问题以及解决方案

关键字：TDD 问题 解决 方案

　　我们组织里曾有许多团队努力采用测试驱动开发(TDD)[1]。偶尔会有一两个开发者成功，但是大多数都失败了。为了更好地找出原因，我调查了团队 的一些成员，发现即使经过了课堂培训，还有更多的事情需要做。虽然这里介绍的问题和想法只适用于中大型的公司，但理解这一点能够帮我们在组织中更好地引入 TDD。

　　我对组员(他们全都接受过培训)的调查显示，以下问题影响了他们：

　　由于经验不足，大家发现自己直接TDD比较困难。

　　TDD培训的例子比实际应用简单得多。

　　需要更多的时间来实验和尝试，不要有赶紧发布软件的压力。

　　实际中应用的语言，比如Visual Basic和JavaScript，在单元测试文档或者课堂练习中从来不会用到。

　　常常会碰到很多遗留代码，而培训时不会介绍如何改进这些代码。

　　永远没有足够的时间用来学习──随时都有尽早交付产品的(人为的)压力，于是没有时间学习提高自己。

　　隐藏的问题

　　我们已经列举了这么多症状，那么冰山下面隐藏的问题是什么呢?

　　测试驱动开发并不是很难学。学习阶段(指形成根深蒂固的习惯的这段时间)一般会持续2到4个月，期间生产效率有所降低[2]。最终的好处显而易见，开发者也能自己保持该项技术，但问题是：怎么才能做到这样?很多开发者仅仅几天之后就放弃了。

　　就我见过的方法而言，大多数依赖于课堂培训(或者e-learning)和一对一的辅导。如果做得好的话，这些方法当然不错，可以作为整个解决方案的一部分，但是我认为还需要更多的方法。

　　课程培训有两个主要的问题：例子太简单，与实际问题关系不大;给大家练习的机会不多。

　　在线培训(Object Mentor和Industrial Logic，以及其它机构提供的培训)，其优点是更有深度。然而练习的机会仍然不多。而且在这些课程里，你与其他学生通常没有交互。听一听你同学和同事的问题，能够加深你的理解。

　　一对一的辅导只能用于团队中的几个人，很难推而广之。在大型企业里面，专家只有几个，而需要帮助的人有成千上万，所以一对一的辅导更是困难。

　　看书是个很好的方法，但是很少有开发者喜欢通过读书学习TDD技术，即使有些人发现看书可以缓慢提高其TDD水平。与其它在线教程类似，看书仍然是只能一个人学习。

　　最后：遗留代码使得TDD难上加难。开发者当然会问这样的问题：“这些对象紧密耦合，怎样才能测试它们?这些代码太复杂了，怎样才能测试这个算法?”

　　一个解决方法

　　那怎样才是好的解决办法呢?前面的方法主要有两个问题：没有深度、缺乏协作。一个完整的解决方案需要结合使用多种学习模式，并需要包含以下多种因素。

原文转自：http://www.ltesting.net