本节书摘来自异步社区出版社《测试驱动数据库开发》一书中的第2章，第2.1节，作者：测试驱动数据库开发，更多章节内容可以访问云栖社区“异步社区”公众号查看。

2.1　TDD中类的角色

测试驱动数据库开发
在测试驱动开发中，一个类的主要作用是提供一种机制，以便许多具有相同行为的对象能够被创建。这一点非常重要，因为测试软件的方式就是通过检查一个单独对象的行为，并据此来预知从该对象的类生成的所有其他实例的行为。

当没有类时，测试仅仅告诉开发者有关某个特定对象的情况。当有了类时，测试会告诉开发者有关对象将如何被创建的情况，并进一步告诉开发者所有其他对象将如何被创建的情况。

2.1.1 可靠的实例化过程

当人们说“我写了一个对象来做X事情”时，事实上并没有写一个对象，而是写了一个类的对象来做X事情，正确的说法应该是“我写了一个类来做X事情”。

人们说他们写对象是因为类和对象之间的界限对他们现在来说是非常模糊的。有一个类通常意味着能得到一个对象，能够得到一个对象通常意味着有一个类。

如果用C#来写一个类的对象，实例化甚至不是要考虑的。这缘于开发了这个类，就意味着它将完全可靠地提供所需要的任意数量的对象，这些对象都能被创建，都能工作，并且都能以该类的其他实例完全相同的方式来工作。

2.1.2 测试检查对象

类能够安全和一致地产生对象这件事是如此的基础，以至于开发人员完全把其当成理所当然的事情。当教一个应用开发人员做测试驱动开发时，我可能会让他为构造方法写一些测试，但是只让他测试需要增加到这个构造方法上的行为，而不需测试刚刚创建好的对象是否被正确地创建了。

从小的方面来讲，那是因为我不认为构造方法比测试一个方法调用更有测试的必要。然而，这不是我不教人测试构造方法进行对象构造的主要原因。

我不教人测试构造方法进行对象构造的真正原因，是因为对我来说从来就没发生过构造方法可能没有构造好一个对象这种情况。当然，这种情况发生的机会还是存在的，但是微乎其微，本书不再考虑这个问题。

以上是对概念进行的一些解释，读者需要换一种方式来考虑这个问题。当在面向对象的系统上进行测试驱动开发时，我实际上是用类之间的关系来进行思考。测试类测试生产类，生产类使用服务类，等等。

然而，实际情况并不是这样的。当为一个生产类写一个测试类时，该测试类真的没有测试该生产类。取而代之的是，该测试类产生了一个内含一堆测试的测试对象。这些在测试对象里的测试接着就获得生产类的实例，并请求这些实例来做事情，然后对结果进行分析和报告。

通常情况下，尽管每次运行都使用全新的测试和生产对象，但都可以数百次地运行同样的测试，并看到完全相同的结果。正是这种可重复性让我确信，在生产部署环境中，生产对象将会正常工作。事实上，上述可预见性允许用类之间的关系来思考，而不是用它们创建的对象之间的关系来思考。

本文仅用于学习和交流目的，不代表异步社区观点。非商业转载请注明作译者、出处，并保留本文的原始链接。