编写数据访问代码测试–不要忘记数据库-CSDN博客

在为数据访问代码编写测试时，必须遵循以下三个规则：

这些规则是显而易见的 。

这就是为什么有些开发人员破坏了它们（我过去也曾破坏它们）的原因。

这篇博客文章描述了为什么这些规则很重要并帮助我们遵循它们。

本系列的第二部分告诉我们，应该通过使用与应用程序相同的配置来配置集成测试。如果我们有充分的理由这样做的话，它也告诉我们可以打破该规则。

让我们研究一种非常普遍的情况，其中我们的集成测试使用与应用程序不同的配置。

我们可以通过以下方法创建数据库：

我也这样做了，这感觉像是一个完美的解决方案，因为

但是，在开始撰写本教程的博客（数据访问代码的写作测试）之后，我意识到这种方法（至少）存在三个问题：

如果数据库是由Hibernate创建的，则我们无法测试我们的迁移脚本是否创建了正常工作的数据库。
Hibernate创建的数据库不一定等于我们的迁移脚本创建的数据库。例如，如果数据库中的表未描述为实体，则Hibernate不会（自然地）创建这些表。
如果要在集成测试套件中运行性能测试，请使用@Index注释配置所需的索引。如果我们不这样做，则Hibernate不会创建这些索引。这意味着我们不能相信性能测试的结果。

我们应该关心这些问题吗？

绝对可以 。

我们必须记住，每项特定于测试的更改都会在我们的测试配置和生产配置之间造成差异。如果差异太大，我们的测试就毫无价值。

如果我们不针对将应用程序部署到开发/测试/生产环境时使用的同一数据库模式运行集成测试，那么我们将面临以下问题：

我们不一定要针对某些功能编写集成测试，因为我们的数据库缺少必需的表，触发器，约束或索引。这意味着我们必须在将应用程序部署到生产环境之前手动测试这些功能。这是浪费时间。
反馈循环比可能要长得多，因为在将应用程序部署到目标环境后，我们注意到了一些问题（例如由错误的迁移脚本引起的问题）。
如果在将应用程序部署到生产环境中时发现问题，则说明问题扑朔迷离，而我们对此予以了覆盖。我不喜欢被大便覆盖。你做？

如果我们想避免这些问题并最大程度地利用数据访问测试的好处，那么集成测试必须使用与将应用程序部署到生产环境中时所使用的数据库模式相同的数据库模式。

当测试有时通过并有时失败时，如果代码，测试或环境没有任何明显变化，则它是不确定的。这样的测试失败，然后您重新运行它们，它们就通过了。此类测试的测试失败似乎是随机的。

非确定性测试的麻烦在于，当它们变成红色时，您不知道是由于错误还是仅是部分非确定性行为。通常，在这些测试中，不确定性失败比较普遍，因此当这些测试变成红色时，您最终会耸耸肩。一旦您开始忽略回归测试失败，那么该测试就没有用了，您最好将其丢弃。

对我们来说很清楚，不确定性测试是有害的，我们应该不惜一切代价避免使用它们。

那么，非确定性数据访问测试的最常见原因是什么？

我的经验告诉我，非确定性数据访问测试背后的最常见原因是在运行每个测试用例之前，无法将数据库初始化为已知状态。

这很可悲，因为这是一个非常容易解决的问题。实际上，我们可以使用以下选项之一解决它：

但是， 我们必须小心，因为只有这些选项才有意义 。

第一种选择是解决此问题的最坏方法。它用不必要的初始化代码使我们的测试方法变得混乱，并使它们非常脆弱。例如，如果我们中断了用于将信息保存到数据库的方法，则使用该方法的每个测试都将失败。

第二个选择要好一些。但是，当我们可以使用经证明有效的现有库时，为什么还要创建一个新库？

我们不应该重新发明轮子。我们应该使用最简单，最好的方法来解决这个问题。我们必须使用现有的库。

当我们为数据访问代码编写测试时，我们可能不得不编写以下测试：

我们必须写什么样的断言？

首先，如果编写测试从数据库中读取信息，我们必须遵循以下规则：

如果我们使用的是将数据库中找到的信息映射到对象的框架或库（例如Spring Data），则断言所返回对象的每个属性值都是正确的是没有意义的。在这种情况下，我们应确保标识返回对象的属性值正确。这样做的原因是我们只能使用我们信任的框架或库。如果我们相信我们的数据访问框架或库能够完成其工作，那么断言所有内容都是没有意义的。
如果我们实现了一个将从数据库中找到的信息映射到对象的存储库，则应确保返回的对象的每个属性值都是正确的。如果我们不这样做，则无法确保我们的存储库正常工作。

其次，如果我们编写将信息写入数据库的测试，则不应在测试方法中添加任何断言。

我们必须使用DbUnit或NoSQLUnit之类的工具来确保将正确的信息存储到数据库中。这种方法有两个好处：