1.3 什么是障碍
测试驱动数据库开发
那么，真正的问题是什么呢？是什么真正阻碍了测试驱动数据库开发的实现？从根本上讲，上面这个问题的答案就是数据库—单独的服务器和数据库实例，即持久化解决方案的运行平台。与一个用于创建一组最终能够被装载到任何特定会话的应用程序的二进制文件的设计相比，一个单独的数据库更像是一个包含 JVM 和一个应用程序的特定会话的进程。
开发人员需要摆脱不良的做法，转向构建不再绑定任何特定数据库实例的数据库设计。
1.3.1 数据库就是对象
数据库就是对象，从面向对象编程的程序员的角度看，它们是长期存在的对象，即便如此，它们仍然是对象。现如今，许多人对待数据库的方式类似于软件开发早期计算机程序员针对计算机本身编程，而不是针对那些能够运行在计算机上的程序编程。
除了一些遗留系统，上述开发应用程序代码的方式因为一些原因而像渡渡鸟1那样绝迹了。最明显的原因是现代计算机环境的复杂性要求能随时随地新增或移除硬件。另一个原因是很多应用程序不得不运行在多种多样的硬件上，或者运行在物理上与开发软件的程序员分离的环境中。
1.3.2 TDD适用于类，不适用于对象
对于数据库领域中的 TDD 来说，其最大的障碍存在于测试的内在本质中。测试天生就是在对象之上进行操作的。当一个人运行手工测试时，他把大量的对象作为接口并与之打交道，包括正使用的应用程序的一个实例和与之交互的大量业务逻辑对象的实例，这些实例根据它们的输入和/或输入产生的结果来作出决定。
其他产业并不是像上面描述的那样做测试。生产需要长期使用的绝对关键产品的公司，如为替换受损髋关节而生产人工髋关节的公司，是需要测试从生产线下来的每一件产品的。而生产那些不是长期使用或不大可能因为产品失效而造成严重人身伤害的产品的公司，如生产铅笔的公司就通过测试产品在统计学领域的显著部分来近似做到测试他们生产的每一件产品。
为什么软件开发人员能够不用测试每一件产品，而仅仅测试他们所做的一些实例呢？
在软件产业，能够像这样做测试可能是因为同一个类的两个对象能做出完全相同的行为。你能用一个类产生任意数量的对象，所有这些对象都具有完全相同的行为。
软件开发者进行开发的这一独特特性，允许一个类的任一实例能作为该类其他每一个实例的模板。这意味着，仅仅对一个对象进行测试就能获得这些对象的类的情况，并能获得该类已经和即将创建的所有对象的情况。
然而，如果开发人员所处的情况与上述情况不同该怎么办？如果一个类的每一个实例都是通过手工或者通过在另一台计算机上的一个不可靠的过程组装成的，那该怎么办？在这种情况下，测试一个对象就不能获得另一个对象的情况。开发者必须测试所构建系统的有统计学代表性的一个子集，而需要做的测试数量将与可以接受的风险数量相匹配。
这就是在数据库世界中开发者所面临的处境。开发者开发了一个设计，很少能有一个容易的方法来将该设计的变化引入到新的或现存的数据库实例中。更多的时候，开发者会在某类数据库的所有各种重要的实例上手工调节设计的变化，这等同于在每一台需要作出更新的计算机上手工修改和检查汇编代码（或者是一些非常初级的源代码），然后在那台计算机上重新编译二进制代码。
当开发者以上述方式开发时，就近乎于需要测试所创建的每一个产品实例。然而，在软件产业，测试通常需要对所测试的对象大动干戈，而开发者不能让产品实例上的实时数据遭受测试带来的那种危险。一些数据库实例，特别是生产数据库，根本就无法进行测试。
1.3.3 我们需要数据库的类
如果开发者需要了解一个数据库的情况，但是不允许对其进行测试，就需要找到一种方法，通过测试一个代理来了解那个数据库是正常工作的。正如本书已经提到的，在应用程序开发世界中允许我们做此事的机制就是类。
因此，测试驱动数据库开发的基础就是建立数据库的类，而不是建立特定数据库的实例。定义的类负责构建和更新测试实例。在从测试实例中获得足够多的反馈来验证对一个类所做的变化之后，接下来该类就以更新测试实例完全相同的方式来更新生产数据库。
相对于那些开发者不想运行任何测试的产品实例来说，通过这种方式可以确保测试实例是个良好的模板。在本书的整个内容中，读者将看到同样的过程不仅允许检查对数据库的修改做了什么，还能检查修改是如何被引入的。当开发者想要把一个数据库的修改发布到任何一个生产环境中时，你完全有信心相信上述修改“是能够工作”的。
1渡渡鸟，或作嘟嘟鸟（Dodo），又称毛里求斯渡渡鸟、愚鸠、孤鸽，是仅产于印度洋毛里求斯岛上一种不会飞的鸟。在被人类发现后仅仅200年的时间里，这种鸟便由于人类的捕杀和人类活动的影响彻底绝灭，堪称是除恐龙之外最著名的已灭绝动物之一。引自百度百科。—译者注
本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。