TDD：
在未通过测试的情况下，请勿编写任何生产代码。
一旦测试失败或编译失败，请停止编写该测试。
测试失败后，立即停止编写生产代码。
两者都重构，然后重复。
循环时间：〜10-60秒。
众说纷纭：
这显然很出色，但实际上，我所看到的更大的问题是，当您不愿使用TDD时，却面临着许多未经测试的传统意大利面条式代码。无数种依赖关系，乍一看，您看不到简单的出路
鲍勃大叔回复：规则1：不要让事情变得更糟。 （banq：如果人可以掌控一切，就可以不让事情变得更糟糕）
哈哈，仅运行测试可能需要60秒以上的时间。一个人可以考虑每次如何>测试10分钟以上...
回复：这源于对单元测试和集成测试之间差异的根本误解。单元测试仅在内存中运行，并且应该可以在几秒钟内执行。即使是数千次测试，也只需几秒钟即可运行。
我一直在做的事情，并推荐给任何人。一旦您开始这样做并习惯了它，生产力就会飞涨！
低于60秒的循环时间听起来不错，但它是本文中最不重要的部分。目标不是直接走得更快。TDD的间接好处是您最终会更快。任何人花更长的时间都没有做错。他们只是在想。思维好。
通常，需求是归结为软件开发中所有（大多数）成功和失败的根源。如果有明确定义的要求，那么以说明形式的TDD就是最好的编码方法。但有时我会做“探索性编码”，尝试在编码时想出自己想要的东西-TDD可能会占用我很多时间。(banq注：测试是代码的看门狗，但是需求是看门狗主人，软件最大难题是需求不断变化，而不是不变。)
TDD是不切实际且被高估的。我在编写代码时会考虑到测试，并在单元测试实际上会增加价值的地方添加测试代码。盲目地尝试达到100％的测试覆盖率通常只会导致维护许多无用的测试。
回复：100％的代码覆盖率不是TDD的目标。此外，遵循TDD与“盲目”执行操作完全相反。任何人对TDD的理解足够深刻，可以提出有效的批评。
在实践中，感觉自然地测试断言要比将测试断言特地写下来要自然得多：)，在纯函数语言中，这是完全自然的，因为每种语言都可以立即进行测试，例如Haskell或LabVIEW。我还将测试人员变成使用API的示例。
