TDD的好处、坏处、及解决不了的问题

TDD的好处、坏处、及解决不了的问题

声明：本人绝不想说服、劝说别人采用和了解TDD。

好处

1. 文档功能: 测试用例可作为规格解释文档，有利于规格的维护和传递；

 

2. 保护网: 有UT的代码是一张优秀的实时保护网，可以帮助开发者快速发现BUG, 在前期解决问题，避免引入问题，重复劳动。实际上，我们经常会有机会几年如一日地解决许多循环出现的问题。今天辛苦解决了，一个月后它又出现了。它会打击你的信心，磨平你的激情。

 

3. 有利于重构和修改BUG：有UT的保护，开发者敢于动手重构代码，一旦引入问题即可快速发现，你清楚地知道改了代码后，还有几个用例不通过。只要让它们通过，则软件的功能就是OK的。这时候你的心态和如履薄冰地召开检视会议是完全不一样的。我的亲身感受: 某次有一个棘手问题，3个用例互相关联，改好了这个，那个又失败了，反之亦然。折磨了我足足3天时间才彻底解决。试想如果没有UT的快速反馈，这个BUG可能花费我20倍的代价，2个月的时间，开发和测试无数次的轮回，才有可能解决。

 

4. 进度掌控：无UT和自动化测试的软件，没有人知道它究竟还有几百个问题。真的，TR5, TR6，都是浮云。理论上来说，开发修改一行代码，测试就应当把整个软件全量测试一次。试想世上有几个组织能这么财大气粗？只能牺牲质量，换回来的，是产品的最终失败。

 

5. 优雅的接口：TDD会强迫程序员做出好的设计，否则测试会很复杂。许多人因此而放弃，认为TDD不现实，违反人性常理。我认为，归根结底，是态度和能力的问题。每个人都高喊质量，却没有几个人以一种开放的心态，去接触，去实践一种新的、也许是更加科学的方法。

 

6. 信心和勇气：采用TDD的团队对自己的产品质量更加有信心，更加有勇气来重构，来写出可维护的代码。世界上依然还有许多团队，在和超长函数、无所不能的上 帝类、大段重复的新员工代码苦苦斗争，长期加班到深夜，但一直没有翻身的机会。除非终于有一天，他们的产品彻底失败了，大家要么走人，要么得到一个重写整 个软件的机会。又3年，代码又会腐烂到一个十分可观的程度，一切照旧。

坏处

1. 技能要求较高；

 

2. 需要写额外的测试代码，比只写开发代码，要多浪费许多钱。

解决不了的问题(简述，不多废话)

1. 设计：采用TDD，一样需要设计。需要更好的设计。否则终有一天你会由于大段地修改测试代码而垮掉。

 

2. 需求分析：它在你真的理解了需求时，对需求分析有帮助，但依然代替不了需求分析。

更多

1. 开源软件的协作必须有自动测试(可以是UT / 系统级测试)。否则必然失败告终。

2. 想省钱的、没有自动测试的软件团队，不知道在微软谷歌怎么样，放在一个二流的公司，必然惨败。