假设你的工作是编写一个程序，在屏幕上输入单词“知道”。

如果我们跳过TDD，我们只是构建我们的程序输出字母a，w，a，r，e，然后我们就完成了。

你猜怎么着？我们还没有完成，因为一个好的开发人员意识到需要反馈来证明该程序有效。所以他们至少运行了一次程序来观察它是否有效。他们甚至可以通过查字典或询问同事来确认他们对拼写的理解，然后发布程序。太棒了！注意，即使在这个简单的例子中，也有一个问题–开发人员在观察结果时做了*手动*测试，以确定程序是否工作。两个月后，另一个程序员被要求在末尾添加一个冒号，以明确其含义。他们开发代码，然后手动查看单词察觉到的：”可能与前一位开发人员对拼写的理解相同，然后他们发布代码。但是，后面的开发人员通常只关注最后的冒号，因为这是他们的贡献。第三个开发人员注意到冒号，并怀疑这个冒号到底重要不重要。开发人员应该知道Ness在冒号之后不是目的，因为这看起来不是一个恰当的词。因此她在“察觉”的末尾添加“ness”，并且在这种情况下，由于被电话呼叫分心或被会议打断而忘记添加冒号。稍后，她运行该程序，观察到打印了“意识”一词，并发布了代码。几天后，有人注意到冐号脱落，经过几次会议后，他们发现为什么会发生这种情况，并联系第3⃣个开发人员，中断她的其他工作，以便她可以纠正这个问题。重复再重复这个程序：做改变，手动测试，发布。注意，在所有四种更改中，开发人员的意图从未记录在自动化测试中，而是由个人自行决定手工完成。

一个聪明的女人曾经说过，永远不要种比你丈夫希望的更多的花园。更多的特性意味着更多的复杂性和更多的代码。考验中的债务增加了。这样编写的代码总是无法维护的，除非手动测试预算总是在增加。开发注定会变慢，除非您的开发预算总是在增加，这样您就可以添加更多的开发人员来处理困难的代码。未除草的花园能变成丛林。

下一集，我们将介绍同样的例子，但是用测试驱动的开发来实现。