在古腾堡以前，“圣经”的印刷是由一队和尚用大量手工制作的-甚至是纸和墨水。在一年多的时间里，许多人参与了“单一圣经”的制作。软件开发也是如此。

IT商店有4到100名开发人员在使用同一应用程序。有了应用程序，源代码可能会旧一些，有时超过十年。要求进行更改的开发人员在进行更改之前需要了解已经存在的内容。僧侣们，尽管他们的工作讲起来应该更容易些，因为他们通常是按部就搬的，但由于不断演变的语言和圣经的隐喻性，一旦遇到了困难-很难知道最初的意思是什么。有些IT公司让开发人员创建一个文档，用来记录程序的功能，但是每个人都知道这些文档并不是非常准确。微测试带来的一个巨大价值是，开发人员的意图被“烘焙”到另一个测试生产程序的程序中。“生产程序”是指打算安装到生产中以便用户可以使用的程序。测试程序永远不会投入生产，因为用户对执行微测试不感兴趣。进行微测试给开发人员带来了中世纪那些留着胡子、脑袋光光的僧侣们从未拥有过的东西：当生产程序偏离了过去开发人员的意图时，自动检查就会升起一个标志。当一个微测试失败时，接下来开发人员重新评估她最近的程序更改，并仔细查看测试程序和生产程序，以确定失败的测试是否需要更新，或者她的策略是否有缺陷。相比于僧侣来说这是一种进步，他们只能求助于休息，与他人商量，祈祷和思考这件事。微测试自动化是对诸如手动测试等中世纪实践的一种进步，因为它们会在几分钟内给开发人员反馈。现在，让我们开始忙碌起来，去创建它们。

在本系列的后面，我们将向您介绍开发人员面临的复杂的TDD执行情况。但在此之前，我们让相关人员进场，并找出为什么开发人员不用TDD。