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

Question

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

• 测试驱动开发：英文全称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的开发方法能快速高效地开发程序。因此这是一个见仁见智的问题。