TDD负经验

Question

你的TDD经验的负面方面是什么？你觉得婴儿步(使测试变成绿色的最简单的方法)烦人和无用吗？您是否发现无值测试(当测试最初有意义，但最终实现检查与其他测试相同的逻辑时)，维护至关重要吗？等。

上面的问题是关于在我的TDD经验中我感到不舒服的事情。因此，我感兴趣的是，其他开发人员是否有类似的感受，他们是如何看待它们的。

感谢那些描述TDD负面方面的文章的链接(Google充满了积极的，经常是狂热的文章)。

Answer 1

就像所有在“敏捷”的旗帜下出现的东西一样，TDD在理论上听起来不错，但在实践中却不太清楚它有多好(而且和大多数“敏捷”的东西一样，你被告知如果你不喜欢它，你就做错了)。

TDD的定义并不是一成不变的:像Kent Beck这样的人要求，非编译测试必须在一行代码之前编写，每一行代码都应该编写以通过失败的测试。预先设计是最小的，所有的东西都是由测试驱动的。只是不起作用。我见过一个使用这种方法开发的大型企业应用程序，我希望这是我职业生涯中看到的最糟糕的代码(它不会太远；尽管有一些有才华的开发人员在做这方面的工作)。据我所见，这会导致大量考虑不周的测试，这些测试主要验证函数调用的发生，当变量为null时抛出异常，而模拟框架得到彻底的锻炼时抛出异常；您的生产代码与这些测试有很大的耦合，并且不会出现持续和容易重构的梦想--事实上，人们甚至不太可能修复坏代码，因为它会破坏所有测试。在这种环境中，软件管理人员宁愿拥有通过测试和代码覆盖率较高的不良软件，也不愿拥有测试较少的优秀软件。

相反，我听说人们认为TDD意味着在高层次上预先设计测试，作为计划阶段的一部分--与架构设计一起。在开发过程中，这些测试可能会随着更多信息的提供而改变，但它们已经得到了仔细的考虑，并为代码的实际操作提供了一个很好的指导。对我来说这很有道理。

Answer 2

这个(克洛尔作者) 富·希基访谈包含以下内容。我百分之百地同情：

生命短暂，一天只有有限的几个小时。所以，我们必须选择如何度过我们的时间。如果我们花在写测试上，那就是我们不花时间去做其他的事情了。我们每个人都需要评估如何最好地利用我们的时间，以便在数量和质量上最大限度地扩大我们的成果。如果人们认为把50%的时间花在写测试上，那么他们的结果就会最大化--对他们来说没问题。我相信这对我来说不是真的--我宁愿花那么多时间思考我的问题。我确信，对我来说，这会产生比其他时间更好的解决方案，更少的缺陷。一个有完整测试套件的糟糕设计仍然是一个糟糕的设计。

唐纳德·库思( Donald )在编者在工作中图书采访中发表的另一份类似声明，来自这里：

说到实际工作，在计算机编程艺术的过程中，你花了十年的时间写你的排版系统TeX。我知道你写的第一个版本的TeX完全远离电脑。Knuth:当我在1977年和78年写TeX的时候，我当然没有识字的编程，但是我确实有结构化的编程。我把它写在一个很大的笔记本上，用铅笔写的。六个月后，在我完成了整个项目之后，我开始在电脑上打字。我在77年10月开始编写这个程序时，在78年3月进行了调试。它的代码在斯坦福的档案里--都是用铅笔写的--当然，当我知道它应该是什么的时候，我会回来改变一个子程序。这是第一代系统，所以很多不同的体系结构都是可能的，必须被抛弃，直到我和它一起生活了一段时间，并且知道那里是什么。这是一个鸡与蛋的问题-你不能排字，直到你有字体，但你不能有字体，直到你可以排字。但是结构化编程给了我不变量的概念，并且知道如何制作我能理解的黑匣子。因此，当我最终调试代码时，我有信心代码会正常工作。我觉得如果在测试之前等六个月，我会节省很多时间。我对代码大致正确有足够的信心。Seibel:节省时间是因为你不会花时间构建脚手架和存根来测试不完整的代码？Knuth:对。

Answer 3

我对TDD的负面体验是我的第一次。对我来说，TDD听起来很棒，我做了多年的QA工作，至今仍记忆犹新。我想把每一个bug都压扁，然后再把它建好。不幸的是，使用TDD并不能保证您会编写好的测试。事实上，我最初的倾向是编写生成简单代码的简单测试。非常简单的代码，包含很少的抽象。与类内嵌交织在一起的非常简单的测试。一旦你有了几千个小小的测试，当你必须改变其中的100个来重构你的代码以使用非常重要的领域概念X时，你肯定不会觉得你在移动得更快。

我的灯亮了-- TDD不是一种测试技能。这是一种设计技巧。它只能引导您找到好的、简单的、可行的代码，并通过实践和不断地了解它所引导您的设计方向。如果您是为了代码覆盖率而编写测试，那么您将创建脆弱的测试。如果您正在编写测试以帮助您设计抽象，那么这只是编写自顶向下代码的一种更严格的方法。首先，您可以从调用者的角度看到代码，这鼓励您让他的生活更轻松，而不是将类的内部元素映射到外部边缘。

我认为TDD是有用的，但我不是教条的。如果那些“无价值测试”使维护变得困难-删除它们！我和其他代码一样对待测试。如果它可以重新分解，使事情变得更简单，那就去做吧！

我没有亲自看过，但我听说有些地方跟踪代码覆盖率和测试计数。因此，如果度量收集是TDD的副作用，那么我也可以将其看作是负面的。我将热情地删除1000行代码，如果这将淘汰20个测试，并降低我的代码覆盖率%，哦，好吧。