Dispatching By File Extension

FileExtensionDataFileLoader picks the loader to delegate to from the file’s extension, so one loader instance can load a mix of formats:

DataFileLoader loader = new FileExtensionDataFileLoader();
IDataSet xmlDs = loader.load("/the/package/prepData.xml");
IDataSet jsonDs = loader.load("/the/package/prepData.json");

The delegate loaders are used only for their format parsing; replacement objects and substrings configured on the FileExtensionDataFileLoader itself are the ones applied, exactly once, regardless of which delegate handled the file.

An unsupported extension throws IllegalArgumentException naming it. Two formats are deliberately not dispatched here:

• CSV — dbUnit’s CSV format is directory-based (CsvURLDataSet expects a directory containing table-ordering.txt), so it cannot share this loader’s one-file-per-path convention. Use CsvDataFileLoader directly, pointed at a directory.
• Full (non-flat) XML — .xml maps to flat XML, the overwhelmingly common case. Use FullXmlDataFileLoader directly for the full XML format.

Each extends AbstractDataFileLoader, which implements the shared DataFileLoader contract: load(String filename) resolves filename as a classpath resource (via Class.getResource()), delegates the actual parsing to the wrapped format, then wraps the result in a ReplacementDataSet. A null/empty filename returns an empty DefaultDataSet rather than throwing.

A simple usage example:

DataFileLoader loader = new FlatXmlDataFileLoader();
IDataSet ds = loader.load("/the/package/prepData.xml");

Caching Parsed Datasets

Every load() parses its file again, so a suite whose tests share the same prep and expected files parses each of them once per test: a SAX parse and the building of the tables for flat XML, and much more for Excel files. CachingFileExtensionDataFileLoader (since 3.6.0) dispatches by extension like FileExtensionDataFileLoader, and parses each file once per run, handing every later load() of that file the parsed dataset:

@DbUnitConfig(dataFileLoader = CachingFileExtensionDataFileLoader.class)

The annotation runtime builds a new loader for each test, so the parsed datasets are held per loader class, not per instance: every instance of the class reuses what the others parsed, and a subclass keeps its own. Replacement objects and substrings still apply per instance, because only the parsed dataset is shared and each load() wraps it in its own ReplacementDataSet.

Use it for immutable classpath fixtures:

• A resource that changes while the JVM keeps running, as in a test daemon or an IDE runner, is not read again until clearCache() drops the loader class’s datasets.
• The shared datasets must be treated as read-only, as every test sees the same ones.
• The datasets stay in memory for the rest of the run, so mind the number of distinct large files, such as Excel workbooks.

Replacement Objects and Substrings

Every loader’s constructors accept replacement object and replacement substring maps, used the same way as with ReplacementDataSet directly (see Decorators, and Dataset Values for the [NULL] convention):

Map<String, Object> replacementObjects = new HashMap<>();
replacementObjects.put("[NULL]", null);

DataFileLoader loader = new FlatXmlDataFileLoader(replacementObjects);
IDataSet ds = loader.load("/the/package/prepData.xml");

You can also add or clear replacements after construction: addReplacementObjects(), addReplacementSubstrings(), removeAllReplacementObjects(), removeAllReplacementSubstrings().

See PrepAndExpectedTestCase for a DataFileLoader used as part of a full prep/expected test setup.