更改数据库模式 &单元测试 [英] Changing Database schemas & unit tests

问题描述

    在我们开始之前，我知道很少有人认为命中数据库的测试不是单元测试".也许集成测试"会是一个更好的名字.无论哪种方式，开发人员都会测试命中数据库.

     Before we start I know a fair few people consider tests that hit the database not "unit tests". Maybe "integration tests" would be a better name. Either way developer tests that hit the database.

    为了启用单元测试，我有一个开发人员本地数据库，我将其清除并在每次测试开始时使用 dbUnit.这一切都运行良好，直到测试使用的表以某种方式发生变化，我必须手动更新所有 XML 数据集.这是一种痛苦.我想其他人一定遇到了同样的问题，并希望找到一个很好的解决方案.那么对于需要填充数据库的测试，您使用什么以及如何处理表定义更改?(虽然我使用 Java，但我对使用不同技术的解决方案持开放态度.)

     To enable unit-testing I have a developer local database which I clear and the populate with a know set of data at the start of each test using dbUnit. This all works well enough until a table used by the test changes in some way and I have to manually update all the XML datasets. Which is a pain. I figure other people must have hit the same problem and hopefully found a nice neat solution to it. So for tests that require populating a database what do you use and how do you handle table definitions changing? (While I use Java I am open to solutions utilizing different technologies.)

澄清一点.我有一个人为的测试，如:

To clarify a little. I have a contrived test like:

void testLoadRevision() {
    database.clear(); // Clears every table dbUnit knows about.
    database.load("load/trevision.xml", "load/tissue.xml");
    SomeDatabaseThingie subject = new SomeDatabaseThingie(databaseProvider);
    Revision actual = subject.load();
    assert(actual, expected);
}

因为我有两个表 - tRevision 和 tIssue.加载的修订版使用来自 tIssue 的少量数据.后来 tIssue 获得了一个修订不关心的新领域.由于新字段非空"并且没有合理的默认值，因此该测试将失败，因为 tIssue.xml 将无效.

In that I have two tables - tRevision and tIssue. A loaded revision uses a small amount of data from tIssue. Later on tIssue acquires a new field that revisions do not care about. As the new field is "not null" and has no sensible default this test it will fail as the tIssue.xml will be invalid.

通过像这样的小改动，编辑 tIssue 并不太难.但是当 XML 文件的数量随着每个流开始膨胀时，工作量就变得很大了.

With small changes like this it is not too hard to edit the tIssue. But when the number of XML files starts to balloon with each flow it becomes a large amount of work.

干杯，
    mlk

Cheers,
    mlk

推荐答案

嗯，在我看来，这是一个结合现有内容的问题.

Well, as I see it, it is a matter of combining what is already there.

上述场景:

1. 编写数据库迁移
2. 应用数据库迁移(在测试运行开始时手动或自动)
3. 观察您的测试是否因违反约束(非空)而中断

您可以扩展它，使您成为一个执行以下操作的小程序:

You could extend it so that you a small program that does the following:

1. 使用 DbUnit XML 填充数据库
2. 应用数据库迁移
3. 在 DbUnit XML(以及 DTD 可选)中就地提取数据库的内容(请参阅 DbUnit 主页 -> DbUnit 常见问题 -> 如何从我的数据库中提取平面 XML 数据集?)
4. 将更新的 DbUnit XML(和 DTD)检查到源代码管理中.

对于应用迁移，我衷心推荐 Flyway.它支持 Sql(带有占位符替换)和基于 Java 的迁移.然后，您可以使用 Maven 插件或使用 API 以编程方式应用迁移.后者非常适合这种情况.

For applying the migration, I heartily recommend Flyway. It supports both Sql (with placeholder replacement) and Java-based migrations. You can then apply the migrations using the Maven Plugin or programmatically using the API. The latter fits this case perfectly.

然后完整的工作流程变成:

The complete workflow then becomes:

1. 编写您的数据库迁移
2. 执行您的 DbUnitXmlDtdUpdater 程序
3. 看着你的单元测试通过

快乐的日子，

阿克塞尔

免责声明:我是 Flyway 的开发人员之一.

Disclaimer: I am one of Flyway's developers.

这篇关于更改数据库模式 &单元测试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！