单元测试数据库驱动应用程序的最佳策略是什么？ [英] What's the best strategy for unit-testing database-driven applications?

问题描述

我使用许多由后端不同复杂性的数据库驱动的Web应用程序。通常，与业务和表示逻辑分开的是 ORM 层。这使得单元测试的业务逻辑相当简单;

I work with a lot of web applications that are driven by databases of varying complexity on the backend. Typically, there's an ORM layer separate from the business and presentation logic. This makes unit-testing the business logic fairly straightforward; things can be implemented in discrete modules and any data needed for the test can be faked through object mocking.

但是测试ORM和数据库本身总是充满了问题，妥协。

But testing the ORM and database itself has always been fraught with problems and compromises.

多年来，我尝试了几种策略，没有一个完全令我满意。

Over the years, I have tried a few strategies, none of which completely satisfied me.

• 使用已知数据加载测试数据库。对ORM运行测试，并确认正确的数据回来。这里的缺点是，您的测试数据库必须跟上应用程序数据库中的任何模式更改，并可能不同步。它还依赖于人工数据，并且可能不会暴露由于愚蠢的用户输入而发生的错误。最后，如果测试数据库很小，它不会显示像缺少索引那样的低效率。 （确定，最后一个不是真正的单元测试应该使用，但它不会伤害。）

• Load a test database with known data. Run tests against the ORM and confirm that the right data comes back. The disadvantage here is that your test DB has to keep up with any schema changes in the application database, and might get out of sync. It also relies on artificial data, and may not expose bugs that occur due to stupid user input. Finally, if the test database is small, it won't reveal inefficiencies like a missing index. (OK, that last one isn't really what unit testing should be used for, but it doesn't hurt.)

加载生产的副本数据库和测试。这里的问题是，你可能不知道在任何给定的时间在生产DB是什么;如果数据随时间变化，您的测试可能需要重写。

Load a copy of the production database and test against that. The problem here is that you may have no idea what's in the production DB at any given time; your tests may need to be rewritten if data changes over time.

有些人指出，这两种策略均依赖于特定数据，单元测试应仅测试功能。为此，我看到建议：

Some people have pointed out that both of these strategies rely on specific data, and a unit test should test only functionality. To that end, I've seen suggested:

• 使用模拟数据库服务器，并仅检查ORM是否正在发送正确的查询

您用于测试数据库驱动应用程序的策略（如果有）？对你最好的是什么？

What strategies have you used for testing database-driven applications, if any? What has worked the best for you?

推荐答案

我实际上使用了你的第一种方法取得了一些成功，不同的方式，我认为会解决你的一些问题：

I've actually used your first approach with quite some success, but in a slightly different ways that I think would solve some of your problems:

1. 保持整个架构和脚本，任何人都可以在签出后创建当前数据库模式。此外，将样本数据保存在通过构建过程的一部分加载的数据文件中。

1. Keep the entire schema and scripts for creating it in source control so that anyone can create the current database schema after a check out. In addition, keep sample data in data files that get loaded by part of the build process. As you discover data that causes errors, add it to your sample data to check that errors don't re-emerge.

使用连续集成服务器进行构建时，您会发现导致错误的数据，请将其添加到示例数据中，以检查错误是否重新出现。数据库模式，加载样本数据和运行测试。这是我们如何使我们的测试数据库保持同步（在每次测试运行时重建它）。虽然这需要CI服务器拥有自己的专用数据库实例的访问和所有权，我说，我们的db模式每天构建3次已大大帮助找到可能不会发现，直到交付之前的错误（如果不是以后）。我不能说我在每次提交之前重建模式。有人吗？

Use a continuous integration server to build the database schema, load the sample data, and run tests. This is how we keep our test database in sync (rebuilding it at every test run). Though this requires that the CI server have access and ownership of its own dedicated database instance, I say that having our db schema built 3 times a day has dramatically helped find errors that probably would not have been found till just before delivery (if not later). I can't say that I rebuild the schema before every commit. Does anybody? With this approach you won't have to (well maybe we should, but its not a big deal if someone forgets).

对于我的群组，用户输入的内容不是必须的（如果有人忘记了，

For my group, user input is done at the application level (not db) so this is tested via standard unit tests.

正在加载生产数据库副本：

这是我上次工作时使用的方法。这是一个很大的痛苦原因的几个问题：

Loading Production Database Copy:
This was the approach that was used at my last job. It was a huge pain cause of a couple of issues:

1. 副本将从生产版本
b $ b
2. 将对副本的模式进行更改，并且不会传播到生产系统。在这一点上，我们有分歧的模式。没有乐趣。

1. The copy would get out of date from the production version
2. Changes would be made to the copy's schema and wouldn't get propagated to the production systems. At this point we'd have diverging schemas. Not fun.

Mocking数据库服务器：

我们也在我当前的工作。每次提交后，我们对注入了模拟db访问器的应用程序代码执行单元测试。然后每天三次执行上面描述的完整db构建。我绝对推荐这两种方法。

Mocking Database Server:
We also do this at my current job. After every commit we execute unit tests against the application code that have mock db accessors injected. Then three times a day we execute the full db build described above. I definitely recommend both approaches.

这篇关于单元测试数据库驱动应用程序的最佳策略是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！