拒绝测试驱动开发（TDD）的10个理由

资讯频道 → 研发管理

2顶
0踩

2011-12-26 17:58 by 正式编辑 sherry617 评论(7) 有8466人浏览

测试 TDD BDD ATDD

在本文内容之前，先来看几个相关的开发方法：

测试驱动开发：英文全称Test-Driven Development，简称TDD，是一种不同于传统软件开发流程的新型的开发方法。它要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动整个开发的进行。这有助于编写简洁可用和高质量的代码，并加速开发过程。
行为驱动开发：英文全称Behavior Driven Development，简称BDD，是一种敏捷软件开发技术，鼓励开发人员、质量保证和非技术或商业参与者都参与到项目中来。
验收测试驱动开发：英文全称Acceptance Test Driven Development，简称ATDD，是一种协同需求发现方法，利用示例和可自动的测试来明确需求，创建可执行的规格。

在我看来，这些都是带动一个团队发展并快速提高产品质量的好方法。但TDD不是万能的，不是每个项目都适用。以下十种情况不建议写测试，如果你的项目符合一种以上，那么TDD以及其他敏捷技术都是多余的。

1. 没有客户

有时候，你正在开发的产品不会被任何人使用，在这种情况下，付出的所有努力都会浪费，没有人会在乎。

2. 客户是挑剔的

有些人非常喜欢测试新软件并寻找错误，这是他们工作的重心，还有一些人喜欢进行栈跟踪，以进行逆向工程。如果你的客户中有这样的人，那么软件中所有的优点都会被忽视。

3. 项目是简单的

如果团队可在短时间内（不超过几个星期）完成项目，且永远不会再对其进行重新维护，那么可维护性、可重用性和可扩展性就变得并不那么重要了，而花在这上的时间和精力就是浪费。

4. 架构是完美的

如果你的架构不需再改进，那么就没有必要让它具有可扩展性。TDD的优势是增量开发流程以及可扩展架构，而如果项目的架构已经够完美了，则TDD就显得画蛇添足了。

5. 文档是完美的

如果API和任何软件的改变都即时记录到文档里，与用TDD创建的文档一样，方便找到你需要了解的东西。如果你的文档是非常完整的，编写测试明显违反了 DRY（Don't Repeat Yourself）原则。

6. 团队没有大的变化并且团队内的人记忆力不错

团队的记忆可以让你回忆起写过的任何一行代码或者当时的开发环境。因此不需要用测试来提醒你代码是干什么的，为什么写它，或如何使用它。但这意味着你的团队不能招募新成员，旧成员也不能离开。这样的话，不写测试也是可以的，因为写了反而会影响团队进度。

7. “Done”意味着代码检查完毕

很多团队有对Done（DOD）的定义，通常指用户可以接收和运行（编码、测试、部署、记录等）软件的情况。然而，大部分更喜欢简单且容易实现的定义。比如说每个成员完成自己的任务就定义为“Done”。而且对于一个项目来说，如果不需要为产品所有者/经理/用户测试代码，则应尽快进入下一阶段。

8. 你的工作是写代码而不是测试

也许你的团队里做测试的人能够快速测试你的代码，并针对有问题的地方及时给你反馈，因此在对代码进行修改的时候，变动的地方在你脑中还有清晰的印象。因此要珍惜测试人员，并确保他们有足够的工作，否则当他们厌倦这份工作后便会跳槽到一个更具挑战性的的公司。

9. 不停地调试导致测试时间过长

和任何有竞争力的公司一样，你的团队必须按时完成任务，这意味着要好好规划并利用时间。由于DoD团队不包括测试，所以无法预测这部分需要多少时间，从开发到QA全部都要折腾无数遍。如果要信守承诺的话，就不能推迟交货时间，否则超过最后期限后上司问起来，你将无法交代。

10. 这只是一个理论

像进化论和重力一样，这些都只是一个理论。即使上述理由都是无效的，也没有人曾经成功地证明，使用TDD的开发方法能快速高效地开发程序。因此这是一个见仁见智的问题。

Via Softwareandi

分享到：

2
顶

0
踩

评论共 7 条请登录后发表评论

7 楼 yunzhu 2012-11-22 10:22

深流水净写道

完全支持，完全本末倒置的一种管理方式。

没看懂文章

6 楼 witcheryne 2012-01-05 17:09

哈哈！！

这个调侃太有意思了

5 楼 fenglin_Java 2012-01-04 21:56

这文章一看久赞同TDD的，因为上述10种可能都是不可能的。

4 楼 yawei 2011-12-28 23:21

TDD确实有独特的意义。我认为其关键就在于把测试开发和设计融合到一起。一旦设计完成，测试就变成了脚手架，限制了程序的自由改动和扩展。

3 楼 futurelife 2011-12-27 13:33

完全是反着说呢，呵呵

2 楼 chloerei 2011-12-27 11:03

没有翻译最后一段，在我看来这段很重要的阿

引用

Test yourself
Now, to test whether or not you should use test driven development, go over the above list. Count how many reasons apply to you. If you scored ten points, don’t use TDD. In fact, if you scored more than one (reason #8 might actually be legitimate), don’t write any code at all. Perhaps you’d be better served choosing a career that has fewer unknowns and moving parts. Perhaps paving roads?

如果十项全中，那么有充分理由不写测试了（估计你的项目也没啥价值了）。
如果中了几项，那么最好不要写代码，你可以选择更稳定的工作，比如铺路。

所以，这是一篇赞同 TDD 的文章。

1 楼深流水净 2011-12-27 09:44

完全支持，完全本末倒置的一种管理方式。

发表评论

您还没有登录,请您登录后再发表评论

2顶0踩