TDD 就是个坑！

脚本之家

你与百万开发者在一起

如果这种编程风格在理论上很伟大，实践中却行不通，那么我们又何必在一棵树上“吊死”？

作者 | Mike Cronin

译者 | 弯月，责编 | 郭芮

出品 | CSDN（ID：CSDNnews）

你没看错，我认为测试驱动开发（Test Driven Development，TDD）很糟糕。更糟糕的是，就好像一个别有用心的人巧妙地掩盖了某些瑕疵，给年轻的开发人员一些不切实际的目标。因此，我想半开玩笑地问你，为一个尚不存在的功能编写测试，你是疯了吗？

为什么我会这样想？

本周我和某位喜欢TDD的开发人员谈了谈真实的经历。我问他们使用TDD的情况，他们滔滔不绝地谈到了所有的好处。但当我更进一步问：“那么，你会在工作中用吗？”他们的回答就大相径庭了。

“这个，关于TDD嘛……”

有人说：“没有时间。”有人说：“我们不是这种文化。”还有人说：“我和我女朋友一直在用TDD，只是你不认识她，她去了另一所学校。”如果TDD真的很棒的话，为什么采用这种方式的人却不多呢？这特别让人失望，因为在训练营的时候，我从来没有看到任何一位老师采用TDD，但他们都谈到了你应该如何利用TDD。听到每个人都反复谈论TDD，我的心情很复杂，因为在内心深处我永远都不明白为什么反着做更好。

那么，TDD究竟有哪些优势呢？

那些鼓吹TDD的人承认，采用TDD确实会降低速度。但是，他们声称生成的代码会非常干净，且思路清晰，从长远来看，还是能够节省时间。但是我觉得TDD需要花费这么多时间，原因还是它的......效率低下。这一点从某天某人尝试TDD的过程中就可以明显地看出来。

事情的经过

那天，当某位开发说向我展示TDD时，我特别兴奋。我们选择了一个功能，然后从一个函数着手，设计了一个测试，最后看着它失败了。然后又从这个函数开始，大约过了十分钟后，他们停下来了。因为他们注意到我们实现函数的方式决定了测试实际上检测不到。于是，我们不得不停止这个功能，然后回去重新写测试。

后来，我们又开始准备测试那个函数，结果却发现我们不知道这个功能如何与系统的其他部分进行交互。于是，我们开始研究代码，想看看这个函数会怎样反应。我们修改了那个功能函数，然后用日志记录了结果。再后来，我们发现如果修改配置文件或修改其他小功能的话会更容易，于是，我们又很快改了一遍。虽然我们花了不少时间，但是终于搞明白了这个功能与系统的交互方式。这时，我又发现：1）这个功能的代码已经写完了；2）我们的测试又一次写错了。

为什么我们尝试TDD失败了？

因为开发软件的工作并不简单。当然，在制作玩具应用程序时，TDD听起来很美好。但在现实生活中，各个功能的复杂度远不止：“函数X接收一个名字某某，然后输出某某你好”。产品的要求往往会在开发期间发生变化，或者你发现这个功能无法按要求运行。也许是你原来的理解有误，你必须重新开始。

所有这些情况都属正常，但每次停下来重新编写测试，都会让问题变得更糟。相比之下，先写代码，然后手动执行QA测试，最后再通过自动化测试模拟这些场景，这样的流程则更为简单。如果已经有人为你准备好了正确的测试，那么你自然可以继续下一个功能或重构，而不必担心会破坏其他功能。将测试当成防护手段，而非导向，才能发挥测试的最大作用，同时还不必担心需要事先预知所有的问题。

但TDD确实有一些优点！

TDD也有很多值得关注的地方。事实上，除了测试之外，TDD的其他方面都很好。TDD背后的想法是，只有你坐下来认真思考功能，才能写出测试。这很好！有太多开发人员（包括我自己）不管不顾一头扎进编程的工作里，却不思考这些代码实际上需要实现什么功能。其实，你只需要记住函数的目标和要求，TDD就起作用了，实在没有必要编写测试。

总结

本文之所以讨论这个话题，是因为测试很重要。

没有经过测试就放入生产的应用程序就像在没有车道的高速公路上行驶。我只想说，TDD就像在实际铺设之前，画了一条高速公路给你。也许你不同意，也许你特别喜欢TDD，而且每天都在使用。但如果你不使用，也没什么大不了！我们必须诚实面对自己。如果某种编程风格在理论上很伟大，实践中却行不通，那么就让我们取其精华弃其糟粕。但令我费解的一点在于：编程的方式有很多种，我们又何必在一棵树上“吊死”？

话说回来，行为驱动开发（Behavior Driven Development，即BDD）是完美无瑕的，如果你不用，你就是傻瓜。

原文：https://itnext.io/test-driven-development-is-dumb-fight-me-a38b3033280c

本文为 CSDN 翻译，转载请注明来源出处。