一些开发人员提倡百分之百地进行测试驱动开发。其他开发者认为TDD是为鸟设计的，根本不做。还有一些开发人员在中间运行TDD超过0%的时间，但不到100%的时间。
我个人在训练TDD的阵营中有一些时间，但不是全部。这是我的理由。
我并不是在每个项目中都使用TDD，甚至根本没有编写测试。但我几乎总是在反馈循环中编程。
“反馈回路法”的工作原理如下。首先，我想到了一个我想实现的小目标（例如，让“hello world”出现在屏幕上）。然后我决定进行一个手动测试，以查看目标是否实现（例如刷新页面并观察）。然后我执行测试，编写一些代码，试图让测试通过，再次执行测试，并以新的目标重复这个过程。
我对TDD的看法是，它只是我本来要做的手工工作的自动化版本。我编写了一个测试，期望“hello world”出现在屏幕上，而不是写一个待办事项，上面写着“让‘hello world’出现在屏幕上”，然后手动刷新页面以查看它是否在屏幕上。所有其他步骤都完全相同。
我发现，当我从事你可能称之为“定义清晰”的工作时，TDD对我来说非常有用。换句话说，我正在努力满足的要求是已知的和指定的。我发现我发现还有其他一些情况下TDD对我来说不是很好。
很容易认为编写代码的原因是为了创建工作产品。但这肯定不是编写代码的唯一原因。代码不仅仅是生产产品的媒介。它也是一种思考的媒介。
这就是敏捷编程中“尖峰”背后的想法。当你在做一个spike时，你没有必要保留你正在写的任何代码。你只是在探索。你会看到你做这件事时的样子，或者你做那件事时的感觉。
你可以把编码想象成弹钢琴。有时候你脑子里已经有了一些音乐片段，你正试图录制一张专辑。其他时候，你只是在胡闹，看你能想出任何值得录制的音乐。这是两种完全不同的乐器使用模式。为了最终录制一些音乐，两者都是非常必要的。
我经常发现，当我编码时，一个尖峰阶段是必要的，例如，一个具有已知总体需求但未知UI细节的功能。在这种情况下，我的测试将充满猜测和占位符，这将是一个笑话的测试，它不会帮助我太多。在这种情况下，我允许自己在高峰时段放弃测试。在我有了一些工作代码并回填测试之后，我会回来。
我没有100%的时间练习TDD。（不过我相信我大部分时间都在练习TDD。）
我认为TDD是我已经在使用的编码工作流程的自动化版本。
生成工作产品并不是编写代码的唯一原因。代码也可以是思考的媒介。
当我使用编码作为一种思维方式时，我发现TDD的好处并不真正适用。