{"id":37023042,"url":"https://github.com/sporniket/spring-test-dbunit","last_synced_at":"2026-01-14T02:45:42.172Z","repository":{"id":57727178,"uuid":"384355103","full_name":"sporniket/spring-test-dbunit","owner":"sporniket","description":"Integration between the Spring testing framework and DBUnit — This fork is developped in the branch \"main\" to easily keep up with the upstream","archived":false,"fork":true,"pushed_at":"2023-07-07T08:32:59.000Z","size":701,"stargazers_count":0,"open_issues_count":3,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-07-07T17:54:58.669Z","etag":null,"topics":["dbunit","integration-testing","spring-test"],"latest_commit_sha":null,"homepage":"","language":"Java","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":"ppodgorsek/spring-test-dbunit","license":"apache-2.0","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/sporniket.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2021-07-09T07:18:18.000Z","updated_at":"2022-09-07T14:44:53.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/sporniket/spring-test-dbunit","commit_stats":null,"previous_names":[],"tags_count":11,"template":false,"template_full_name":null,"purl":"pkg:github/sporniket/spring-test-dbunit","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sporniket%2Fspring-test-dbunit","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sporniket%2Fspring-test-dbunit/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sporniket%2Fspring-test-dbunit/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sporniket%2Fspring-test-dbunit/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/sporniket","download_url":"https://codeload.github.com/sporniket/spring-test-dbunit/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/sporniket%2Fspring-test-dbunit/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":28408737,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-01-14T01:52:23.358Z","status":"online","status_checked_at":"2026-01-14T02:00:06.678Z","response_time":107,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dbunit","integration-testing","spring-test"],"created_at":"2026-01-14T02:45:41.446Z","updated_at":"2026-01-14T02:45:42.141Z","avatar_url":"https://github.com/sporniket.png","language":"Java","readme":"# DBUnit integration for the Spring testing framework\n\n## What is it?\n\nSpring DBUnit provides integration between the Spring testing framework and the popular DBUnit project. It allows to set up and tear down database tables using simple annotations as well as checking expected table contents once a test completes.\n\nThe project can be configured to run DBUnit tests using a Spring TestExecutionListener.\n\nThis project was forked from [springtestdbunit/spring-test-dbunit](https://github.com/springtestdbunit/spring-test-dbunit) in order to continue its maintenance.\n\n### Versioning\n\nThe versioning of this project follows the one of the Spring Framework:\n\n* Major version matches the one of the Spring Framework\n* Minor version is used for dependency upgrades\n* Patch version is used for bug fixing\n\nThe dependencies used are:\n\n* Spring Framework 5\n* DBUnit 2.6\n* JUnit 5\n\n## How to use this project\n\nAll artefacts of this project are available on Maven's central repository, which makes it easy to use in your projects.\n\nIf you are using Maven, simply declare the following dependencies:\n* spring-test-dbunit-core:  \n`    \u003cdependency\u003e`  \n`        \u003cgroupId\u003ecom.github.ppodgorsek\u003c/groupId\u003e`  \n`        \u003cartifactId\u003espring-test-dbunit-core\u003c/artifactId\u003e`  \n`        \u003cversion\u003e${spring-test-dbunit.version}\u003c/version\u003e`  \n`    \u003c/dependency\u003e`\n\n* spring-test-dbunit-sample:  \n`    \u003cdependency\u003e`  \n`        \u003cgroupId\u003ecom.github.ppodgorsek\u003c/groupId\u003e`  \n`        \u003cartifactId\u003espring-test-dbunit-sample\u003c/artifactId\u003e`  \n`        \u003cversion\u003e${spring-test-dbunit.version}\u003c/version\u003e`  \n`    \u003c/dependency\u003e`\n\n`spring-test-dbunit-core` is the only mandatory one, the others are optional.\n\n## Configuration\n\nTo have Spring process DBUnit annotations you must first configure your tests to use the `DbUnitTestExecutionListener` class. To do this you need to use the Spring `@TestExecutionListeners` annotation. Generally, as well as `DbUnitTestExecutionListener`, you will also want to include the standard Spring listeners as well. Here are the annotations for a typical JUnit 5 test:\n\n    @SpringJUnitConfig\n    @ContextConfiguration\n    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,\n        DirtiesContextTestExecutionListener.class,\n        TransactionalTestExecutionListener.class,\n        DbUnitTestExecutionListener.class })\n\nSee the Spring JavaDocs for details of the standard listeners.\n\nIn order to access the database, Spring DBUnit requires a bean to be registered in your test context. By default a bean named `dbUnitDatabaseConnection` or `dataSource` can be used (see the Advanced Configuration section below if you need to use another name). The bean can reference either a `IDatabaseConnection` or more typically a standard Java `DataSource`. Here is a typical XML configuration for accessing an in-memory Hypersonic database:\n\n    \u003cbean id=\"dataSource\" class=\"org.springframework.jdbc.datasource.DriverManagerDataSource\"\u003e\n        \u003cproperty name=\"driverClassName\" value=\"org.hsqldb.jdbcDriver\" /\u003e\n        \u003cproperty name=\"url\" value=\"jdbc:hsqldb:mem:paging\" /\u003e\n        \u003cproperty name=\"username\" value=\"sa\" /\u003e\n        \u003cproperty name=\"password\" value=\"\" /\u003e\n    \u003c/bean\u003e\n\nOnce you have configured the `DbUnitTestExecutionListener` and provided the bean to access your database you can use the DBUnit annotations.\n\n## Setup and TearDown\n\nNote: You need to complete the steps from the configuration section above before any annotations can be used. Without appropriate configuration DBUnit annotations will be silently ignored.\n\nThe `@DatabaseSetup` and `@DatabaseTearDown` annotations can be used to configure database tables before tests execute and reset them once tests have completed.\n\n### Setup\n\nThe `@DatabaseSetup` annotation indicates how database tables should be setup before test methods are run. The annotation can be applied to individual test methods or to a whole class. When applied at the class level the setup occurs before each method in the test. The annotation value references a file that contains the table's dataset used when resetting the database. Typically this is a standard DBUnit XML file, although it is possible to load custom formats (see below).\n\nHere is a typical setup annotation. In this case a file named `sampleData.xml` is contained in the same package as the test class.\n\n    @DatabaseSetup(\"sampleData.xml\")\n\nIt is also possible to reference specific resource locations, for example:\n\n    @DatabaseSetup(\"/META-INF/dbtest/sampleData.xml\")\n\nBy default, the setup will perform a `CLEAN_INSERT` operation, this means that all data from tables referenced in the DataSet will be removed before inserting new rows. The standard DBUnit operations are supported using type attribute. See the JavaDocs for full details.\n\n### TearDown\n\nThe `@DatabaseTearDown` annotation can be used to reset database tables once a test has completed. As with `@DatabaseSetup`, the annotation can be applied at the method or class level. When using `@DatabaseTearDown` use the value and type attributes in the same way as `@DatabaseSetup`.\n\nNote: If you are running a teardown in conjunction with a `@Transactional` test you may need to use an alternative configuration. See the section on below.\n\n## Expected results\n\nThe `@ExpectedDatabase` annotation can be used to verify the contents of the database once a test has completed. You would typically use this annotation when a test performs an insert, update or delete. You can apply the annotation on a single test method or a class. When applied at the class level, verification occurs after each test method.\n\nThe `@ExpectedDatabase` annotation takes a value attribute that references the DataSet file used to verify results. Here is a typical example:\n\n    @ExpectedDatabase(\"expectedData.xml\")\n\nThe `@ExpectedDatabase` annotation supports two different modes. `DatabaseAssertionMode.DEFAULT` operates as any standard DbUnit test, performing a complete compare of the expected and actual datasets. `DatabaseAssertionMode.NON_STRICT` will ignore tables and column names which are not specified in the expected dataset but exist in the actual datasets. This can be useful during integration tests performed on live databases containing multiple tables that have many columns, so one must not specify all of them, but only the 'interesting' ones.\n\nNote: If you are using this annotation in conjunction with a `@Transactional` test you may need to use an alternative configuration. See the section on below.\n\n## Transactions\n\nIf you have configured DBUnit tests to run using the `DbUnitTestExecutionListener` and are also using the `TransactionalTestExecutionListener`, you may experience problems with transactions not being started before your data is setup, or being rolled back before expected results can be verified. In order to support `@Transactional` tests with DBUnit, you should use the `TransactionDbUnitTestExecutionListener` class.\n\nHere are the annotations for a typical JUnit 5 test:\n\n    @SpringJUnitConfig\n    @ContextConfiguration\n    @Transactional\n    @TestExecutionListeners({ DependencyInjectionTestExecutionListener.class,\n        DirtiesContextTestExecutionListener.class,\n        TransactionDbUnitTestExecutionListener.class })\n\nTransactions start before `@DatabaseSetup` and end after `@DatabaseTearDown` and `@ExpectedDatabase`.\n\n## Advanced configuration of the DbUnitTestExecutionListener\n\nThe `@DbUnitConfiguration` annotation can be used if you need to configure advanced options for DBUnit.\n\nThe databaseConnection attribute allows you to specify a specific bean name from the Spring Context that contains the database connection. When not specified the names or can be used. The bean must be either an `IDatabaseConnection` or a `DataSource`.\n\nThe `dataSetLoader` or `dataSetLoaderBean` attribute allows you to specify a custom loader that will be used when reading datasets (see below). If no specific loader is specified a `dbUnitDataSetLoader` bean will be used from the `ApplicationContext` (or if no such bean exists, the `FlatXmlDataSetLoader` will be used).\n\nThe `databaseOperationLookup` attribute allows you to specify a custom lookup strategy for DBUnit database operations (see below).\n\n## Working with multiple connections\n\nIt is possible to configure Spring Test DBUnit to work with multiple connections within the same test. First declare multiple `DataSource` or `IDatabaseConnection` beans in your application context. For example, here is XML configuration for two in-memory databases:\n\n    \u003cbean id=\"dataSource\" class=\"org.springframework.jdbc.datasource.DriverManagerDataSource\"\u003e\n        \u003cproperty name=\"driverClassName\" value=\"org.hsqldb.jdbcDriver\" /\u003e\n        \u003cproperty name=\"url\" value=\"jdbc:hsqldb:mem:paging\" /\u003e\n        \u003cproperty name=\"username\" value=\"sa\" /\u003e\n        \u003cproperty name=\"password\" value=\"\" /\u003e\n    \u003c/bean\u003e\n    \u003cbean id=\"customerDataSource\" class=\"org.springframework.jdbc.datasource.DriverManagerDataSource\"\u003e\n        \u003cproperty name=\"driverClassName\" value=\"org.hsqldb.jdbcDriver\" /\u003e\n        \u003cproperty name=\"url\" value=\"jdbc:hsqldb:mem:customers\" /\u003e\n        \u003cproperty name=\"username\" value=\"sa\" /\u003e\n        \u003cproperty name=\"password\" value=\"\" /\u003e\n    \u003c/bean\u003e\n\nYou then need to use the `@DbUnitConfiguration` on your test to link to the connections:\n\n    @DbUnitConfiguration(databaseConnection={\"dataSource\", \"customerDataSource\"})\n\nThe `@DatabaseSetup`, `@DatabaseTearDown` and `@ExpectedDatabase` annotations all have a `connection` attribute which can be used if you need to target a specific connection. If you don't specify a `connection` the first `databaseConnection` from `@DbUnitConfiguration` will be used (\"dataSource\" in the example above).\n\nSpring Test DBUnit Annotations are repeatable so if you are using Java 8+ you can use several with the same test. For example:\n\n    @Test\n    @DatabaseSetup(value = \"insert.xml\")\n    @DatabaseSetup(connection=\"customerDataSource\", value=\"insert-custs.xml\")\n    public void testInsert() throws Exception {\n        // Inserts \"insert.xml\" into dataSource and \"insert-custs.xml\" into customerDataSource\n        // ...\n    }\n\nIf you are using an earlier version of Java, you will need to use one of the wrapper annotations:\n\n    @Test\n    @DatabaseSetups({\n        @DatabaseSetup(value = \"insert.xml\")\n        @DatabaseSetup(connection=\"customerDataSource\", value=\"insert-custs.xml\")\n    })\n    public void testInsert() throws Exception {\n        // Inserts \"insert.xml\" into dataSource and \"insert-custs.xml\" into customerDataSource\n        // ...\n    }\n\n## Custom IDatabaseConnections\n\nIn some situations you may need to create an `IDatabaseConnection` with a specific DBUnit configuration. Unfortunately, the standard DBUnit DatabaseConfig class cannot be set up easily using Spring. In order to overcome this limitation, the `DatabaseConfigBean` provides an alternative method to configure a connection; with standard getter/setter access provided for all configuration options. The `DatabaseDataSourceConnectionFactoryBean` accepts a configuration property and should be used to construct the final connection. Here is a typical example:\n\n    \u003cbean id=\"dbUnitDatabaseConfig\" class=\"com.github.springtestdbunit.bean.DatabaseConfigBean\"\u003e\n        \u003cproperty name=\"skipOracleRecyclebinTables\" value=\"true\"/\u003e\n    \u003c/bean\u003e\n    \u003cbean id=\"dbUnitDatabaseConnection\" class=\"com.github.springtestdbunit.bean.DatabaseDataSourceConnectionFactoryBean\"\u003e\n        \u003cproperty name=\"databaseConfig\" ref=\"dbUnitDatabaseConfig\"/\u003e\n    \u003c/bean\u003e\n\nNOTE: In most circumstances, the username and password properties should not be set on the `DatabaseDataSourceConnectionFactoryBean`. These properties will cause DBUnit to start a new transaction and may cause unexpected behaviour.\n\n## DataSet loaders\n\nSeveral dataset loaders are already available to read from:\n\n* flat XML files, (default)\n* CSV files,\n* XLS files.\n\nIf you need to load data from another source you will need to write your own DataSet loader and configure your tests to use it. Custom loaders must implement the `DataSetLoader` interface and provide an implementation of the `loadDataSet` method. The `AbstractDataSetLoader` is also available and provides a convenient base class for most loaders.\n\n### CSV datasets configuration\n\nUnlike XML and XLS files, CSV files have a very basic structure which doesn't allow multiple tables to be defined in a single file.\n\nThe `CsvUrlDataSetLoader` therefore relies on a folder containing:\n\n* a `table-ordering.txt` file listing the tables in the order they should be imported,\n* a dedicated `\u003ctable name\u003e.csv` file for each table which has to be imported.\n\nThe dataset parameter should therefore point to that folder, not to individual files.\n\nAnother point to keep in mind is that the current implementation of DBUnit uses commas as a value separator, not semicolons.\n\n### SQL Loader control datasets configuration\n\nSimilarly to CSV files, SQL datasets can only contain one table per file.\n\nThe `SqlLoaderControlDataSetLoader` therefore relies on a folder containing:\n\n* a `tables.lst` file listing the tables in the order they should be imported,\n* a dedicated `\u003ctable name\u003e.ctl` file for each table which has to be imported.\n\nThe dataset parameter should therefore point to that folder, not to individual files.\n\n### Overriding the dataset loader\n\nAlthough the dataset loader is usually defined on the `DbUnitConfiguration` annotation, it is possible to override it on the following annotations:\n\n* `DatabaseSetup`\n* `DatabaseTearDown`\n* `ExpectedDatabase`\n\n## Custom DBUnit Database Operations\n\nIn some situations you may need to use custom DBUnit DatabaseOperation classes. For example, DBUnit includes `org.dbunit.ext.mssql.InsertIdentityOperation` for use with Microsoft SQL Server. The `DatabaseOperationLookup` interface can be used to create your own lookup strategy if you need support custom operations. A `MicrosoftSqlDatabaseOperationLookup` class is provided to support the aforementioned MSSQL operations.\n\nSee above for details of how to configure a test class to use the custom lookup.\n\n## Known issues\n\n### NullPointerException when loading XLS files\n\nA NullPointerException can sometimes occur when loading data from XLS files. This issue is related to how the XLS file was edited. Once content has been submitted into cells and even if these cells are later made blank, the XLS file might still store those empty cells. This will cause the line count for the file to be incorrect, hence the exception.\n\nThe solution is quite easy, simply delete the last rows of your file, even if they already seem blank.\n\nYou can check the resolution by debugging `org.dbunit.dataset.excel.XlsTable.getRowCount()` and making sure it returns the correct number of rows.\n\n## Please contribute!\n\nHave you found an issue? Do you have an idea for an improvement? Feel free to contribute by submitting it [on the GitHub project](https://github.com/ppodgorsek/spring-test-dbunit/issues).\n","funding_links":[],"categories":[],"sub_categories":[],"project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsporniket%2Fspring-test-dbunit","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fsporniket%2Fspring-test-dbunit","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fsporniket%2Fspring-test-dbunit/lists"}