TDD体验的负面影响是什么？您是否发现婴儿脚步（使测试呈绿色的最简单方法）烦人且无用？您是否发现无价值测试（当测试最初具有意义但最终实现时会检查与其他测试相同的逻辑）维护的重要性吗？等。
上面的问题与我在TDD体验中感到不舒服的事情有关。因此，我很想知道其他开发人员是否也有类似的感受，以及他们对此有何看法。
感谢您对描述TDD不利方面的文章的链接（Google充满了积极且经常是狂热的文章） 。
#1 楼
就像在“敏捷”旗帜下的所有事物一样，TDD在理论上听起来不错，但实际上并不清楚它有多好（而且像大多数“敏捷”事物一样，您也会被告知，如果不这样做）像这样，您就错了。）TDD的定义并非一成不变：像肯特·贝克（Kent Beck）这样的人要求必须在单行代码之前编写非编译测试，并且每行代码应该编写一行代码以通过失败的测试。前期设计极少，并且一切都取决于测试。就是行不通。我已经看到使用这种方法开发的大型企业应用程序，我希望这是我职业生涯中看到的最糟糕的代码（不会太遥远；尽管有一些有才华的开发人员正在研究它）。从我所看到的结果来看，它导致了大量的考虑不周的测试，这些测试主要验证了函数调用的发生，当变量为null且模拟框架进行了彻底的练习时，抛出了异常（whoop-de-whoop）；您的生产代码与这些测试紧密相关，并且没有出现恒定且易于重构的梦想-实际上，由于所有测试都会破坏，人们更不可能修复错误的代码。在这种环境下，软件经理宁愿拥有通过测试和较高代码覆盖率的劣质软件，也不愿拥有较少测试的优质软件。
相反，我听说人们认为TDD意味着要预先设计测试作为规划阶段的一部分，以及建筑设计。随着更多信息的获得，这些测试可能会在开发过程中发生变化，但是已经对其进行了仔细的考虑，并为代码的实际操作提供了很好的指南。对我来说，这很合理。
评论
+1“作为计划阶段的一部分，在高层进行测试的高级设计-与建筑设计一起进行”对我来说也听起来更加合理。
–史蒂文·杰里斯（Steven Jeuris）
2011年8月4日12:45
@Aaronaught敏捷并不意味着没有计划，而是意味着及时计划。
–亚当·贾斯基维奇（Adam Jaskiewicz）
11年8月4日在13:54
@Adam Jaskiewicz：我喜欢“没有预先计划”的事情。来吧，按照定义，计划是预先的。如果您没有事先计划，但在活动期间，您根本就没有计划；你即兴创作。 ;-)
– CesarGon
2011年8月4日在16:48
@Adam-“人们真的会在迭代的第一天直接跳入编码吗？”是的。那是“敏捷”的人。我工作的最后一个地方（因为没有做到“敏捷”而被解雇），他们做了一个完整的3个月的发布周期，而从未计划过一行代码或只编写一页文档。是的，代码很糟糕，是的，该软件运行缓慢，笨拙且有错误。我加入的那天，经理自豪地告诉我他们是“伦敦最敏捷的商店”。他们肯定是。
–user23157
2011年8月4日在18:20
可能会增加另一个问题：只要它通过测试，就必须是好的。没关系，测试本身很可能是有缺陷的，因此会导致假阴性和/或假阳性。当然，要求“ 100％测试覆盖率”之类的东西从定义上讲是完美的，会导致无用的测试，这些测试实际上不测试任何东西，而仅仅是为了达到100％的覆盖率而编写的，未记录的代码，因为您的覆盖率计数器包含注释如未发现的代码等。
– jwenting
2011年8月9日下午6:22
#2 楼
这次（Clojure作者）Rich Hickey的采访包含以下内容。我感到100％的同情：生命短暂，一天只有有限的几个小时。因此，我们必须选择如何度过自己的时间。如果我们花时间编写测试，那么这就是我们不花时间做其他事情的时候。我们每个人都需要评估如何最好地度过时间，以便在数量和质量上最大化我们的结果。如果人们认为花费50％的时间来编写测试可以最大程度地提高测试结果-对他们来说还可以。我确定这对我来说不是真的，我宁愿花时间去思考自己的问题。我敢肯定，对于我来说，这将产生比其他任何时间都更好的解决方案，更少的缺陷。具有完整测试套件的不良设计仍然是不良设计。
Donald Knuth在《 Workers》采访中的《 Coders》中的另一条类似声明，是从此处复制粘贴的： ：说到实际工作，在编写计算机编程艺术的过程中，您花了十年的时间来编写排版系统TeX。我了解您完全不在计算机上编写了TeX的第一个版本。
克努斯（Knuth）：当我最初在1977年和78年写TeX时，我当然没有读写编程的经验，但确实有结构化的编程经验。我用铅笔写在一个大笔记本上。六个月后，当我浏览完整个项目后，我开始在计算机上打字。在我于77年10月开始编写程序时，在78年3月进行了调试。斯坦福档案中的代码全部用铅笔写了，当然，当我了解了它应该是什么之后，我当然会回来修改一个子程序。这是第一代系统，因此可能有许多不同的体系结构，必须丢弃，直到我忍受了一段时间之后才知道存在什么。这是一个鸡与蛋的问题-在拥有字体之前您无法排版，但在可以排版之前您无法字体。但是结构化编程给了我不变的想法，并且知道如何制作我能理解的黑匣子。因此，我有信心在我最终调试它时该代码将起作用。我觉得如果我等六个月再进行任何测试，将会节省很多时间。我有足够的信心认为代码正确无误。
Seibel：节省时间是因为您不必花时间搭建脚手架和桩来测试不完整的代码？
努斯：对。
评论
我认为您必须查看正在执行的工作类型。 Knuth和Hickey在谈论新的（创新）应用程序的设计。如果您看一下TDD在哪里流行（广泛概括），那么您就会意识到，以TDD方式编写的大多数应用程序已经具有众所周知的架构。
–sebastiangeiger
11年8月4日在11:26
我可以看到Rich Hickey的含义，但我想补充一下：我的经验是，在编写测试时，您需要真正考虑设计并考虑如何使代码可测试。经验，可以带来更好的设计。
–尼古拉斯H
11年8月4日在11:51
鉴于OP要求获得TDD的负面经验，您的示例均与该问题无关，因为两者均未显示TDD的实际应用。
–温斯顿·埃韦特（Winston Ewert）
2011年8月4日15:05
@Michael Borgwardt：将测试添加到现有的良好设计中相对容易，以消除实现中的错误。但是摆脱不良的设计通常意味着完全重写。因此，主要目标应该是正确设计。执行起来以后更容易修复。
–乔纳斯·普拉卡（Joonas Pulakka）
2011年8月4日在16:18
大多数业务应用程序没有由Donald Knuth编写和/或维护的好处。应用程序的生命周期通常比其主要开发周期更长。我希望人们在我当前的项目上写更多的测试。现在，维护就像是无限回归的雷区。
–马特H
2011年8月5日，0：49
#3 楼
我对TDD的负面经历是我的第一个经历。 TDD对我来说听起来很棒，我做质量检查已经很多年了，但仍然让我感到恐惧。我想压扁每个错误，然后再构建它。不幸的是，使用TDD并不能保证您会编写出良好的测试。实际上，我最初的倾向是编写能够生成简单代码的简单测试。真正简单的代码，几乎没有抽象。与类内部结构交织在一起的真正简单的测试。而且一旦您完成了数千个小小的测试，当您必须更改其中的一百个重构代码以使用非常重要的领域概念X重构代码时，您肯定不会感觉自己在以更快的速度前进。光亮对我来说-TDD不是测试技能。这是一种设计技能。它只会使您在实践中获得良好，简单，可行的代码，并不断意识到它所带给您的设计指导。如果出于代码覆盖率的目的而编写测试，则将创建脆弱的测试。如果您正在编写测试以帮助您设计抽象，那么这只是编写自顶向下代码的一种更严格的方法。您首先要从调用者的角度看代码，这鼓励您简化调用者的工作，而不是将类的内部镜像到其外部边缘。
我认为TDD很有用，但我不教条。如果这些“无价值的测试”使维护变得困难，请删除它们！我将测试与其余代码一样对待。如果可以将其重构并简化操作，那就去做吧！
我还没有亲眼看到它，但是我听说有些地方跟踪代码覆盖率和测试计数。因此，如果指标收集是TDD的副作用，那么我也可以认为这是负面的。我会热情地删除1000行代码，如果那会过时20次测试并丢弃我的代码覆盖率％，那就好了。
评论
您在第2段中将其钉牢。
–谢尔顿·沃肯汀（Sheldon Warkentin）
2011年8月5日，12：58
“我个人还没看过它，但是我听说有些地方跟踪代码覆盖率和测试计数”，我生活在这样的环境中，实际上没有任何代码抛出过，因为这样做会导致测试失败。在我开始调试实际的测试之前，发现其中的很多缺陷都非常严重，他们迫使代码产生不正确的结果以使测试通过。从那时起，我提出了一个问题：“谁在测试测试”，到目前为止，我从未得到TDD社区满意的答复。单元测试的单元测试，有人吗？
– jwenting
2011年8月10日在7:36
@jwenting-这个轶事很好地支持了Rei的论点。我发现TDD的回归保护方面在实践中被夸大了，即使这在理论上是一个扎实的想法。必须将测试保持在与生产代码相同的水平才能正常工作，并且以这种方式对待非生产代码有点不自然-我在硬件模拟器，代码生成器中看到相同的“代码腐烂”，等所有的时间。
–史蒂夫·杰克逊（Steve Jackson）
2011年8月10日在12:32
“与类内部结构交织在一起的真正简单的测试” <-那里就是您的问题。仅测试公共接口。 TDD！= UT
–史蒂文·劳（Steven A. Lowe）
2012-2-10 17:47
@ StevenA.Lowe-我知道了，但是9年前还不清楚：)“ TDD不是测试技能”
–史蒂夫·杰克逊（Steve Jackson）
2012年2月10日17:50
#4 楼
我要走到这里，用残酷的诚实宣布这实际上是一种浪费时间的仪式。 （在大多数情况下。）我买了一本关于单元测试的书，其中还讨论了TDD，虽然我同意UT的好处，但在尝试了TDD约100小时后，我给了出于各种原因。我有点交叉张贴，但是TDD：
比真实的文档更好。
不捕获错误或回归。
如果我应用一些功能性编程和可组合性概念，并不能使我的设计最终真正地变得更好。
最好花时间进行代码审查或完善文档和规范。
>当经理看到数百个绿色图标列表时，会给他们一种错误的安全感。
通过有限的输入-输出映射提高了算法实现的生产率。
笨拙，因为您可能知道自己是TDD的结果，但您对它为什么如此有效，为什么您的设计以它们的方式表现出来并没有任何了解。要成功地做到这一点就必须做到这一点。有人坚持认为，如果从项目开始时团队中的每个人都没有坚持不懈地进行TDD，那只会让您受苦。其他人则坚称，没有人会按此书进行TDD。如果这两个都是对的，那么无论他们是否意识到，TDD的从业者都在遭受痛苦。
当然，如果有人争论说，以类似TDD的方式做事，您会对于可以轻松使用TDD进行设计的设计，要实现这一目标的方法要快得多，即通过实际研究可组合性的概念。那里有很多资源，甚至还有很多严格的数学理论（主要在函数式编程中，而且在其他领域中）。为什么不花所有的TDD时间来学习？
在文化上，TDD表现出是一种礼仪习惯的症状。它感到内s；它鼓励程序而不是理解；它有大量的教义和口号（如果客观地看待它，“伪造它直到制造出来”确实非常令人震惊）。 Wikipedia对“仪式”一词的定义实际上是很恰当的：
在心理学中，仪式性一词有时在技术意义上用于
，是被系统地使用的重复行为。一个
中和或防止焦虑的人；这是强迫症
的症状。
评论
非常有趣的观点：仪式。在某些方面，您还可以感觉到程序员对技术的承诺被认为仅与他对TDD的遵守成正比。
–yalestar
2011年8月9日在19:56
我会说在某些情况下它可以改进设计，但是大多数情况下，这是设计需要高度模块化，定义非常明确且易于使用的公共界面的时候。在这种情况下，在实现库本身之前为它编写测试可以帮助消除公共接口中的错误，并强加这种模块化。
– jwenting
2011年8月10日在7:39
@jwenting人们之所以进行TDD，是因为他们不知道是什么使设计模块化，因此他们永远无法从40英寸的自行车上卸下35英寸的训练轮。如果您了解概念，则进行模块化设计始终是一项可管理的任务，因为设计的每个难题在其概念上都将变为模块化，因此其规模将可管理。我不同意TDD在强制模块化方面是有效的，但我不同意必须强迫人们创建模块化设计。模块化设计是一种完美的教学和学习技能。
–宫阪丽
2011年8月10日9:03
@jwenting关于公共接口的可用性，TDD从业者在这方面有两种观点，这都是不希望的：将所有事物公开，以便可以对其进行测试，或者将其私有化（如果无论如何也不应对其进行测试） 。前者迫使不必要的实现细节暴露给最终用户（这可能会被滥用或利用），而后者则迫使单元测试更接近系统测试。当然，您可以使用单元测试工具来访问私有数据，但这在TDD中没有太大意义。
–宫阪丽
2011年8月10日9:16
@Kall在那次采访中，他说“时间增加了大约15％到35％”，而不仅仅是您引用他时的15％。该研究还只涉及Java / C ++ / C＃（可能是C＃2，给定日期）-相同的命令式OOP范式的所有语言。使用功能性语言（甚至在C＃3中），我的生产率肯定提高了15％以上，并且可能提高了35％以上，而且编写无状态，可组合代码的错误产生的次数也要少得多，即测试可以改善的错误类型，因为这两种方法都能解决完全相同的问题。换句话说，当然可以减少60-90％的错误，但是相比之下呢？
–宫阪丽
2011-10-28 18:59
#5 楼
另外，我注意到与TDD有关的另一个问题是：TDD导致开发团队的工作重点从质量代码转移到了测试用例和代码覆盖率上！我个人不喜欢TDD，因为它会使我失去创造力，并使软件开发成为一个乏味的机械过程！明智地使用单元测试用例很有用，但是当对待软件开发目标时，它会成为负担。
我认识一个是经理的人，一旦沉迷于TDD，他在技术上就会变得呆板。对他来说，这是一件神奇的事情，他相信他可以用最少的可维护代码为他架构不良的软件带来神奇的解决方案。更不用说那个项目发生了什么-它在他的手中惨败，而他所有的测试用例都是绿色的。我想TDD帮助他获得了一些统计信息，例如“我的案例中有99/100是绿色的”等，这就是他痴迷的原因，因为他永远无法评估质量或提出改进设计的建议。 >
评论
听起来像PHB地狱！它使我想起引入奖金计划的公司-当然发生的是，开发人员而不是专注于质量代码，而是专注于满足奖金要求。不可避免地，您会获得更糟糕的代码。 （这里也可以比喻当前的银行危机：-）
– TrojanName
11年8月24日在11:27
TDD并不是项目管理技术，因此也难怪您想成为经理的人失败了。另一方面，我并没有觉得自己没有创造力，甚至更有创造力，因为开发测试会自动为我提供代码的另一种观点。但是，我同意重点必须放在生产代码上，并且测试不应破坏良好的软件体系结构。
– Alex
2011-11-25 19:33
代码覆盖率是单元测试而不是TDD的关注点。 TDD只关心通过公共接口进行的功能和测试。
–史蒂文·劳（Steven A. Lowe）
2012-2-10 17:49
#6 楼
我的主要负面经验是尝试使用TDD来编辑另一个没有测试或非常非常基本的集成测试的程序员的代码。当我添加功能或解决上述代码问题时；我希望先编写一个测试（TDD方式）。不幸的是，代码紧密地耦合在一起，如果不进行大量重构，我将无法测试任何东西。重构是一项很棒的练习，但是需要使代码进入可测试状态。在执行此步骤之后，我没有任何制衡手段来查看我的更改是否破坏了任何内容；只需运行应用程序并检查每个用例即可。
另一方面，向TDD项目中添加功能/修复bug变得非常简单。从本质上讲，使用TDD编写的代码通常与一些小片段分离开来。
无论如何，TDD是一个准则。遵循它，直到发现最大的效率。体面的测试范围和解耦的代码，编写良好的代码。
评论
如果很难编写单元测试，则通常存在关注点分离差的问题。我不认为这是TDD的错，如果有的话很快就会使这些问题显而易见。
–汤姆·克尔（Tom Kerr）
2011年8月4日在22:25
这不是TDD的负面体验，而是糟糕的代码的负面体验。
–宫阪丽
2011年8月5日在20:35
#7 楼
我的经验是，在设计系统时，有时会过分依赖我的测试。从根本上讲，我对具体实施细节的了解太低，无法退后一步来查看大图。这通常导致不必要的复杂设计。我知道，我应该重构代码，但有时我会觉得，通过更频繁地退后一步，可以节省很多时间。话虽如此，如果您有一个类似的框架，在您的体系结构决策非常有限的轨道上，这些问题基本上是不存在的。
另一个问题是您盲目地信任测试。事实是-与其他任何代码一样，您的测试也可能存在错误。因此，对测试和实施都同样重要。
评论
也许您应该为测试编写一些测试！ ：p ...我孩子，我孩子
–阿伦
2011年8月9日17:02
+1 +1 +1 +1（如果我有3个虚拟帐户）。句子＃2非常有见地，没有太普遍的TDD确认偏见。
–tgm1024--莫妮卡遭到虐待
19年4月7日在13:20
#8 楼
作为TDD的忠实拥护者，我有时会看到这些缺点。出于几乎100％的代码覆盖率的诱惑，编写太多的测试。我认为，不必为抛出异常的每种情况编写用于简单属性获取器/设置器的测试
，以通过不同的层检查相同的功能。 （例如：如果您有一个单元测试来检查每个参数的输入有效性，那么也不必通过集成测试来重复所有这些测试）。
测试代码的维护成本类似的测试，仅稍有不同（通过代码复制（又名复制粘贴继承）创建）。如果您已经拥有一个，则很容易创建一个类似的对象。但是，如果您不重构测试代码，则通过消除代码重复到辅助方法中，如果业务代码的实现细节发生更改，则可能需要一些时间来修复测试。
如果时间紧迫，您可能会想消除损坏的测试（或将其注释掉）而不是进行修复。这样一来，您就失去了测试的投资
评论
+1：“出于接近100％的代码覆盖率的目的而编写过多的测试的诱惑。”：我一次陷入了这个陷阱，花了很多时间编写所有这些单元测试之后，我在代码中发现的唯一三个错误是单元测试未涵盖，可以通过逐步调试代码轻松找到。
–乔治
2012-12-10 9:59
#9 楼
作为TDD值得的游戏开发者，我还没有遇到过多个场景。它所处的实例是一段本质上纯数学的代码，需要一种可靠的方法来同时测试大量边缘情况-很少需要。也许有一天这将改变我的想法，但是在XP实践中，无情地重构的想法以及代码以其自身的形式发展的想法更为重要，这对我来说是最大的生产力。詹姆斯·纽克尔克（James Newkirk）的一篇论文引述：
简单-“最简单的方法可能起作用吗？”
信息很清楚。根据今天的需求，设计和编写软件。不要试图预见未来，而要展现未来。它通常会以非常难以预测的方式做到这一点，从而使预期成本往往太高而无法承受。“
勇气和加强反馈的概念在我看来，他提到的循环也是生产力的关键。
评论
问题是，没有单元测试，您如何知道无情的重构导致代码执行相同的操作？根据我的经验，我发现，根据问题，与编写自己的代码相比，花费更少的时间来编写测试+代码！原因主要归结为以下事实：对于某些问题，我可以尝试进行重构并自动进行重新测试，比手动进行测试要快得多，这可以显着提高迭代速度。
– Mark Booth
2011年8月4日12:21
对于游戏，通常可以看到结果。如果它们能够被看到并且看起来足够好，那么它们将被接受，因为无论如何游戏都是一种主观体验。另一方面，以例如。以《暗黑破坏神2》为例，战斗公式中的错误数量表明TDD可以带来巨大的价值，并为他们节省了大量的补丁工作。对于定义明确的问题（例如求解方程式）以及运行时无法通过视觉输出判断的问题，TDD是确保正确性的必备条件。但这只是大多数游戏中代码的一小部分。
–工程师
2011年8月4日在12:27
还值得一提的是，由于模拟运行的速度较高，因此与模拟运行时坐在屏幕上的百万行日志文件相比，最好在模拟运行时实时在屏幕上实时观察变量。
–工程师
2011年8月4日12:29
根据我的经验，单元测试使重构更加容易。
–汤姆·克尔（Tom Kerr）
2011年8月4日在14:34
@Nick游戏行业的最大问题是截止日期，这总是-“我们必须在半年前交付”。我认为在时间受限制的环境中，时间与单元测试不符。在某些情况下，这不是一个正确的决定，但在大多数情况下，无需编写测试就可以更快地交付。取决于，真的取决于...
–编码器
11年8月8日在21:53
#10 楼
TDD狂热者。对我来说，它们只是一长串宗教骗子之一，敲响了我的门，试图证明我的行事方式受到了不可挽回的破坏，而拯救的唯一途径就是耶稣，肯特（Kent Back）或单元测试。
IMO，他们最大的谎言是TDD将引导您拯救更好的算法设计。请参见用TDD编写的著名的Soduku求解器：在这里，在这里，在这里，在这里和这里
，并比较一下Peter Norvig sudoku求解器，它不是通过使用TDD而是通过老式的工程来完成的：http：// norvig.com/sudoku.html
评论
看，我们可以对此进行争论。但是自从我从Fullsail大学毕业并获得游戏设计学位以来，我还有很多工作要做。根据我的课程和要求很高的工作，我可以说TDD确实胜过了懒惰的程序员逐行（缺乏设计）的疯狂开发。看起来我不会在说，但这是事实：大多数上师范大学的CS程序的开发人员大多没有毕业，绝大多数以压倒性多数没有进入软件开发的人，最重要的是，大多数人都没有获得成功。 ， 逐行。 Fullsail大学有一个
–僵尸
2011年10月28日在17:11
仅需完成测试驱动开发的完整课程，就可以使开发人员真正走上正轨（与在c ++中实现链表相反）。
–僵尸
2011-10-28 17:12
链接坏了！
–lmiguelvargasf
16年4月3日在20:54
这是很多年后的事，但是@Zombies，请查看“ Confirmation Bias”。在大学中，我们所有人在计算机科学中所学的很多东西正好属于这一类。看一下“魔术数字”的随意使用以及C语言中goto的疯狂打击。
–tgm1024--莫妮卡遭到虐待
19年4月7日在13:35
哈哈，我正在拖钓……我很久以前就写道，我已经忘记了那个小宝石。
–僵尸
19年4月7日在13:49
#11 楼
我对TDD的负面体验（可能有限）只是知道从哪里开始！例如，我将尝试做一些TDD，要么不知道从哪里开始测试琐碎的事情（我可以新建一个Foo对象，还是可以将Quux传递给Baz等？不能测试任何东西），或者如果我试图在现有项目中实现它，那么我发现我必须重写各种类才能在TDD中使用它们。最终结果是我很快就完全放弃了这个概念。我常常是整个公司中唯一知道什么是单元测试（TDD或其他）的人，这可能并没有帮助。为什么这是一件好事。
评论
这就是模拟框架的用处。使用Mock对象而不是Quux和Baz直接实例化Foo，然后可以调用要测试的函数，然后检查是否使用期望的函数调用了模拟。模拟对象是使单元解耦并使单元可测试的使能技术。这就是单身人士之所以邪恶的原因，因为您常常不能仅仅嘲笑他们。 * 8'）
– Mark Booth
2011年8月4日在16:32
#12 楼
如果您从这些“狂热的”文章中使用TDD，您将获得错误的安全感，即您的软件没有错误。评论
除了知道对于给定的一组输入，您的软件返回给定的一组输出之外，您还能得到其他感觉吗？
–user1249
2011年8月4日在20:22
只要您了解tdd是开发过程，而不是解决任何类型问题的黄金法则，就可以了。但是，大多数建议使用此过程的人都忘记了它的开发过程，以及其他任何过程都有光明的一面和黑暗的一面。他们对所有人说，如果您将使用tdd，则将拥有无错误的软件，因为您将使用测试覆盖所有功能。通常这是不对的。最好的方式是对每种情况（或至少是功能）进行测试，但是测试是程序（有错误），并且仅仅是黑盒测试。
– Dainius
2011年8月5日下午6:37
#13 楼
TDD有一些好处：，您将重点放在如何调用代码以及首先要期待的内容上（因为您首先编写测试），而不是着眼于解决问题然后粘上来自应用程序的调用。模块化使得更容易模拟和包装。
测试可确保您的程序在重构之前和之后均能正常工作。这并不意味着您的程序没有错误，但是它可以以相同的方式工作。
TDD与长期投资有关。当您达到应用程序的维护模式时，付出的努力就会得到回报，并且如果该应用程序没有计划达到这一点，您可能永远也无法收回投资。
我认为TDD的红绿色循环的婴儿步骤类似于飞机的检查清单。起飞前检查飞机上的每件事物既烦人又乏味，特别是如果它很简单（TDD婴儿步），但已发现它增加了安全性。除了验证一切正常之外，它实际上还可以重置飞机。换句话说，飞机在每次起飞前都会重新启动。
评论
利用简单的单元测试也可以实现受益点2，而无需使用TDD方法。好处1，您无论如何都要做。 （着重于该API）仍然可以完全使用TDD创建一个糟糕的API，但是可以的，您可以保证它可以工作（用于笔试）。
–史蒂文·杰里斯（Steven Jeuris）
2011年8月4日12:34
问题不是在询问TDD的好处。对此已经有很多其他问题。
– Aaronaught
2011年8月4日13:18
@aaronaught，我正在解决他的痛点。
–user1249
2011年8月4日15:05
答案应该解决这个问题。
– Aaronaught
2011年8月4日15:09
@aaronaught，然后写一些。
–user1249
2011年8月5日，0：10
#14 楼
我对TDD的负面经验是我对许多新颖的和炒作的感觉。实际上，我之所以喜欢TDD，是因为它确保了我的代码的有效性，甚至更重要：在添加新代码或进行任何类型的重构之后，我可以识别失败的测试。让TDD烦恼的是有关它的许多规则或指南。因为它仍然很新，所以我们大多数人都有成为TDD初学者的经验。因此，对我们中的某些人来说行之有效的，对其他人而言可能行不通。我想说的是，没有真正的“错误或正确”方法来执行TDD：这对我和我的团队（如果有的话）都有效。
只要您编写测试-在生产代码之前或之后都没关系，恕我直言-我不确定测试驱动是否真的意味着您必须遵循现在所说的所有准则，因为尚未证明它们是日常工作的理想解决方案。如果您发现编写测试的更好方法，则应将其发布在博客中，在此处进行讨论或撰写有关该测试的文章。因此，在大约十年的时间里，我们可能已经分享了足够的经验，可以判断在特定情况下哪种TDD规则可以被认为是好还是不好。
评论
+1很棒的评论。实际上，它不一定非要是一种真实的方法，或者根本就不是。
– unpythonic
11年8月6日在7:44
#15 楼
我发现TDD在紧急系统方面的表现很差。我是一名视频游戏开发人员，最近使用TDD创建了一个系统，该系统使用多个简单行为来为实体创建逼真的动作。例如，有些行为负责将您从不同类型的危险区域移开，而某些行为则负责将您移至不同类型的有趣区域。将每种行为的输出融合在一起将形成最终的动作。
系统的内在性很容易实现，而TDD在这里用于指定每个子系统应该负责什么是有用的。
但是，当涉及到行为如何相互作用，更重要的是随着时间的推移它们如何相互作用时，我遇到了问题。通常没有正确的答案，尽管我的初步测试通过了，但是QA可以继续查找系统无法正常工作的极端情况。为了找到正确的解决方案，我不得不反复考虑几种不同的行为，如果我在检查游戏中的新行为之前每次都更新测试以反映新行为，那么我可能最终会一次又一次地抛出测试。所以我删除了这些测试。
我应该有更强大的测试来捕获QA发现的边缘情况，但是当您拥有这样的系统位于许多物理和游戏系统之上时， “随着时间的推移处理各种行为，确切地说明正在发生的事情变成了一场噩梦。
我几乎可以肯定我的方法是犯错误的，就像我说过的那样，TDD可以发挥作用出色，甚至支持一些优化重构。
评论
您最近是否在为工作中的项目尝试过TDD？您的经历如何？ 9年后，您对TDD仍然有同样的感觉吗？
– MasterJoe
20-4-22在19:13
@ MasterJoe2爆炸过去！我的思想已经成熟：TDD非常重要，但是应该阻止它到达代码中面向玩家的顶部，因为那只是“有趣”而不是“正确”。例如，您不会TDD说蓝色外壳会寻找领导者，而要寻找领导者功能，而下移路径功能也能工作，等等。您也许可以对蓝色外壳进行功能测试寻找领导者并走了一条路，但是作为事后测试，不是TDD！
–tenpn
20-4-23在20:40
#16 楼
我已经编写了不止一次的代码，因为它太笨拙，第二天就将其丢弃。我使用TDD重新启动，解决方案更好。因此，我对TDD的负面经验还不多。但是，话虽如此，我还是花了一些时间思考问题，并在TDD空间之外提出了更好的解决方案。评论
通常，比起第一次尝试（无论是否为TDD），第二次尝试可以使您对问题有更多的了解。
– wobbily_col
2014年5月12日上午8:41
评论
我的猜测是，您不会听到很多有关人们负面经历的诚实答案，因为TDD仍处于“早期采用者”状态，并且大多数有兴趣并愿意尝试的人都不够客观。根据其相对优点进行评估。整个行业通常要花几年时间才能真正确定新流程和新技术的长期效果，即使那样，由于缺乏控制，也很难获得直接的答案。不过，这是一个好问题，祝您获得有用的答案！您在互联网上发现负面情绪时遇到麻烦了吗！!
@Job（可能还有其他）：别忘了他问过TDD，而不是单元测试。 TDD！=单元测试。
我很想回答这个问题，但是我真的不想开始，因为这会占用我一半的时间。
当我发现自己花了足够的时间在bug上时，似乎我可以花更少的时间在编写每件东西之前编写测试，而我不会采用test-first-all-things-TDD。相反，我会羞愧地垂头丧气，开始寻找新的职业。与您说的错误无关？设计？是。而已。就是这样。通过给自己一个安全网和一个继续愚蠢地工作的许可，您还没有学到关于健壮设计的事情。如果要发现真正的问题，请收起IDE，并尝试阅读代码。