dbunit性能最佳实践

在我以前的任务之一中，我们进行了数百个涉及数据集的集成测试，尽管不是在DBUnit中进行的-测试环境是从头开始编写的，因为它是一家可以负担这类东西的非常大的公司。

数据集是分层组织的。被测系统由几个（5-10）模块组成，测试数据遵循该模式。单元测试脚本如下所示：

 include(../../masterDataSet.txt)
 include(../moduleDataSet.txt)

 # unit-specific test data
 someProperty=someData

我不记得某些奇怪的工具将属性名称直接映射到数据库记录。

相同的模式可以应用于DBUnit测试。在主数据集中，您可能总是需要放置记录-像字典一样，数据库的初始加载，就好像要从头开始安装一样。

在模块数据集中，您将记录涵盖模块中大多数测试的测试用例。我不认为对您的70个数据库表进行的平均测试是吗？即使应用程序是整体的，您肯定也必须具有一些可以构成模块的功能组。尝试围绕它组织模块级测试数据。

最后，在测试级别上，只需使用此特定测试所需的最少记录数来修改测试集。

这种方法具有学习的巨大好处。因为数据文件很少，所以实际上您实际上已经开始记住它们。您可以轻松地分辨出两个数据集有何不同，而不是看到数百个仅因不明显的细节而有所不同的大数据集（每次重新测试都必须找出这些细节）。

最后说说性能。在我的2.4 GHz 2核WinXP计算机上，DBUnit测试涉及：

• 掉了14张桌子
• 创建14张桌子
• 插入ca. 100条记录
• 执行测试逻辑，

需要1-3秒。日志显示前三个操作花费的时间不到一秒钟，Spring消耗了大部分测试时间。该逻辑由每个测试执行，以避免测试订单依赖性。一切都在具有嵌入式Derby的VM中运行，这可能就是为什么它这么快的原因。

编辑：我认为DBUnit XML数据集不支持包含其他测试文件，可以通过对所有集成测试使用基类来克服它，例如：

public class AbstractITest {

    @Before
    public void setUp() throws Exception {
        //
        // drop and recreate tables here if needed; we use 
        // Spring's SimpleJdbcTemplate executing drop/create SQL
        //
        IDataSet masterDataSet = new FlatXmlDataSetBuilder().build("file://masterDataSet.xml");
        DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, dataSet);
    }
}

public class AbstractModuleITest extends AbstractITest {

    @Before
    public void setUp() throws Exception {
        super.setUp();
        IDataSet moduleDataSet = new FlatXmlDataSetBuilder().build("file://moduleDataSet.xml");
        DatabaseOperation.CLEAN_INSERT.execute(dbUnitConnection, moduleDataSet);
    }
}

public class SomeITest extends AbstractModuleITest {
    // The "setUp()" routine only here if needed, remember to call super.setUp().

    @Test
    public void someTest() { ... }
}