database - 对数据库驱动的应用程序进行单元测试的最佳策略是什么？

Question

我使用了很多网络应用程序，这些应用程序由后端复杂程度各不相同的数据库驱动。通常，有一个 ORM与业务和表示逻辑分离的层。这使得对业务逻辑进行单元测试非常简单；事情可以在离散模块中实现，并且测试所需的任何数据都可以通过对象模拟来伪造。

但是测试 ORM 和数据库本身一直充满问题和妥协。

多年来，我尝试了一些策略，但没有一个能让我完全满意。

• 使用已知数据加载测试数据库。针对 ORM 运行测试并确认返回正确的数据。这里的缺点是您的测试数据库必须跟上应用程序数据库中的任何架构更改，并且可能会不同步。它还依赖于人工数据，并且可能不会暴露由于愚蠢的用户输入而发生的错误。最后，如果测试数据库很小，它不会显示像缺少索引这样的低效问题。 (好吧，最后一个并不是真正应该使用单元测试的目的，但这并没有什么坏处。)

• 加载生产数据库的副本并对其进行测试。这里的问题是您可能在任何给定时间都不知道生产数据库中有什么；如果数据随时间变化，您的测试可能需要重写。

有人指出，这两种策略都依赖于特定数据，单元测试应该只测试功能。为此，我看到了建议:

• 使用模拟数据库服务器，仅检查 ORM 是否发送正确的查询以响应给定的方法调用。

您使用什么策略来测试数据库驱动的应用程序(如果有)？什么最适合您？

Answer 1

我实际上已经使用了您的第一种方法并取得了相当大的成功，但我认为以稍微不同的方式可以解决您的一些问题:

1. 将整个模式和用于创建它的脚本保存在源代码管理中，以便任何人都可以在 checkout 后创建当前的数据库模式。此外，将示例数据保存在由构建过程的一部分加载的数据文件中。当您发现导致错误的数据时，将其添加到示例数据中以检查错误是否再次出现。

2. 使用持续集成服务器构建数据库架构、加载示例数据并运行测试。这就是我们保持测试数据库同步的方式(在每次测试运行时重建它)。虽然这要求 CI 服务器可以访问和拥有自己的专用数据库实例，但我说每天构建 3 次数据库模式极大地帮助发现了可能在交付前才可能发现的错误(如果不是更晚的话) ).我不能说我在每次提交之前都重建架构。有人吗？通过这种方法，您将不必这样做(也许我们应该这样做，但如果有人忘记了也没什么大不了的)。

3. 对于我的团队，用户输入是在应用程序级别(而非数据库)完成的，因此这是通过标准单元测试进行测试的。

正在加载生产数据库副本:
这是我在上一份工作中使用的方法。这是几个问题的巨大痛苦原因:

1. 该副本与生产版本相比会过时
2. 将对副本的架构进行更改，但不会传播到生产系统。在这一点上，我们会有不同的模式。不好玩。

模拟数据库服务器:
我们也在我目前的工作中这样做。每次提交后，我们都会对注入(inject)了模拟数据库访问器的应用程序代码执行单元测试。然后我们每天三次执行上述完整的数据库构建。我绝对推荐这两种方法。