如何看待tdd及其他以测试驱动开发的方法?

谢邀。

首先解答这个问题之前，需要有一个基本的共识，要不要测试？如果你认为不要测试，那么就谈不上要不要“测试驱动开发”了，就没必要讨论今天的问题了。

既然要写测试，那么我们讨论一下：“补单元测试、面向覆盖率写测试”，还是“测试驱动开发”。我选第二种。

我个人理解的TDD的精髓不在于要不要提前写好测试，写好自动化测试。而是做一个事情之前，想一想你做的这个事的目的是什么，你做的事情能不能被验证，还是一厢情愿的个人揣测（我加了这行代码，它理应能解决我的问题）。

同时，功能越纯粹，测试也越简单，为了测试好写会让你实现的方法独立性（职权分离）非常强，输入是什么输出是什么在实现之前就已经想好，从而使代码的思路也会特别清晰。

再者提前想好你的实现部分需要满足哪些场景（test。case），会让你的代码更加完善

至于写测试，是一种讲这种人为验证的过程机器化乃至自动化，同时好的测试非常业务化，即使没有代码基础的业务经理都能读懂你的代码，从而知道你验证了哪些场景，你的验证方式是什么。不然你说你验证了，证据呢? 这个时候你可以给别人说，“喏，这是我的测试代码”。

要不要测试？

要不要先准备测试？

要不要先写单元测试？

TDD Not Unit Test Driven Design

最近正在练习并提高自己tdd的能力。知乎的邀请还真是精准。

我觉得测试驱动开发是每一个人软件开发人员所应该具备的基本能力。这是一种好的开发实践，为什么说他好，有三大原因。

其一，在写代码前弄清楚需求，避免花费时间写多余的代码，消除浪费。其实我们大部分程序员在写代码前都认为自己已经很清楚需求了，但往往不是的，不用测试先限定出自己的期望，往往会跑偏，或者把自己绕进去，或者过度设计，时间就这样浪费掉了。所以测试驱动开发就是要在写代码之前明确这一步我要做什么，思路清晰，小步前进，不写多余的代码。我写的每一行代码都是有意义，实现的功能是符合期望的。

其二，驱动出更好的设计和更加易于维护与扩展的代码。直接写代码和先写测试再写代码虽然都可以实现同一个功能，但写出来的代码会很不一样。（这里排除个例，就是说大部分情况）测试驱动开发会先写测试，然后写仅仅让测试通过的代码，然后在保证测试通过的前提下重构代码，然后代码更加易读，揭示意图，消除重复，减少依赖。当必要时抽出一些方法或者类。这样写出的代码后期去维护是十分方便的。

其三，保证质量。在测试金字塔中，单元测试是处在最底层，它可以最快速，最低成本的反馈出代码的质量问题。如果我们采用测试驱动开发的方式，自然在开发业务代码的过程中就完成了这一任务。如果先写代码，过后为了保证质量去补测试，反倒是浪费时间的。而且事实是，你会发现你写的代码很难去加测试，依赖太多，测试也很难写。最终需求变了，要改代码，也要改测试。而且补加的测试往往比测试先行的测试更难改。

或许有人会反问，测试驱动开发需要一部分工作量去写测试拖慢开发速度。其实恰恰相反，写测试所花费的那一点点时间比过度设计，或者开发出来不符合期望反复修改，以及出了bug查找bug修复bug所花费的时间要少得多。所以tdd难以实施的原因有两个：

一个是开发人员没有意识到tdd的优点，在心里没有认可它。另一个最主要的原因是tdd 的能力不够。很多人觉得tdd反倒拖慢了自己的开发速度，不是tdd本身的问题，而是自己对tdd的使用还不够熟练，还没有掌握。所以是需要不断的刻意练习，才能让tdd成为一种习惯。才能在开发过程中得心应手。

答着现在就在通过刻意练习培养自己tdd 的习惯。 当然上面说的这些可能更偏向于单元测试。但整体来说这种测试先行的思想是通用的，像bdd也是一样的，提前框定出要实现的行为，满足需求，避免浪费。