Overview

VerifyTableDefinition (org.dbunit, since 2.4.8) defines one database table to verify: which columns to include or exclude from the comparison, which ValueComparer (if any) to use per column, and (since 3.5.0) whether row sorting for the comparison considers only those included/excluded columns. It is consumed by PrepAndExpectedTestCase — one instance per table you want verified after a test runs.

Fields

Constructors

VerifyTableDefinition has 7 constructor overloads. All of them delegate to the 6-argument canonical form; pick whichever overload matches what you need to configure:

VerifyTableDefinitionVerifier

Every constructor’s last step is verifyTableDefinitionVerifier.verify(this), using a DefaultVerifyTableDefinitionVerifier by default. It catches one specific configuration conflict: a column listed in both columnExclusionFilters and columnValueComparers — excluded from comparison, yet also given a specific comparer — and throws IllegalStateException with a message naming the table and column. This is a fail-fast check at construction time, not at comparison time, so a misconfigured VerifyTableDefinition breaks loudly wherever it’s built (commonly a static field or factory method) rather than surfacing later as a confusing assertion failure.

getVerifyTableDefinitionVerifier()/setVerifyTableDefinitionVerifier() expose the verifier instance for reuse (e.g. calling .verify(…​) again manually) or replacement with a custom VerifyTableDefinitionVerifier. Note the setter has no automatic effect on verification already performed — construction always verifies using the default verifier, since the setter can only be called on an instance that already exists.

Sort Mode

PrepAndExpectedTestCase sorts both the actual and expected tables before comparing them row-by-row. By default (sortOnFilteredColumnsOnly is false) it sorts the actual table by all of its native database columns and the expected table by only the columns its dataset file declares — typically every column except a generated/identity one, since its value is unknown ahead of time.

That default breaks down for a table whose generated column is excluded from comparison when production code does not insert rows in a predictable order — for example, Hibernate reordering a batch insert. The database still assigns the excluded column’s value in insertion order, so the actual table ends up sorted primarily by that unpredictable value while the expected table sorts by data content, misaligning same-data rows and failing the comparison even though both sides hold identical data. See issue #672.

Set sortOnFilteredColumnsOnly to true to sort both actual and expected tables by only the columns that survive columnExclusionFilters/columnInclusionFilters instead — the same columns that end up compared — so an excluded generated column never participates in the sort:

VerifyTableDefinition table = new VerifyTableDefinition(
        "IDENTITY_TABLE", new String[] {"IDENTITY_TABLE_ID"});
table.setSortOnFilteredColumnsOnly(true);

Or set it directly at construction time instead of calling the setter afterward. The common case — no include filter needed — uses the five-argument constructor:

VerifyTableDefinition table = new VerifyTableDefinition("IDENTITY_TABLE",
        new String[] {"IDENTITY_TABLE_ID"}, null, null, true);

If you also need an include filter, use the six-argument canonical constructor instead:

VerifyTableDefinition table = new VerifyTableDefinition("IDENTITY_TABLE",
        new String[] {"IDENTITY_TABLE_ID"}, null, null, null, true);

Default is false, preserving the historical sort-by-all-columns behavior. It remains safe whenever every column needed to tell otherwise-identical rows apart is present on both the actual and expected tables. Opt in per table whenever such a distinguishing column is absent from the expected table - typically because it is excluded from comparison - regardless of whether that column happens to be generated/identity or not.

Usage Examples

This page covers the class’s shape. For full usage — static shared instances, test-specific factory methods, and wiring `ValueComparer`s per table — see PrepAndExpectedTestCase.