Database initialization for testing

[Max-Goebel]

How will we initialize database for testing? Which data format will we use to represent the data used to this initialization?

• Solution 1: Importing a database dump
• Solution 2: Creating test data with DB-Unit
• Solution 3: Creating test data with Flyway (this solution has been discussed here )
• Solution 4: Using the CRUD-functions of the code under test (maybe with the builder pattern)

All solutions except solution 1 have to deal with the problem that data changes must be undone before the next test execution starts. For solution 2, DB-Unit provides tools to do this. For solution 3 and 4 the following alternatives exist:

• A: Creating a snapshot before test execution and reset the database with this snapshot afterwards (or at the beginning of the next test execution)
• B: Entities created by the software will use the hibernate sequence that is initialized with 1000000. All master-data have to use IDs lower 1000000. At the beginning of an integration test, all entities with an ID >= 1000000 must be deleted
• C: Remove created data explicitly with the delete-functions of the system under test’s API.

The purpose of this ticket is to clear these questions:

• Which solution is the best?
• How should this solution be supported by OASP?

[anmaso]

Since a batch functionality is considered also to be part of OASP, could it be also an alternative to do this initialization? or will it be overkill? kind of eating our own dog food :-)

[amarinso]

Sorry for last comment author, I didn't realized I was logged in github with other user.

[Max-Goebel]

Using the batch layer for initializing the database would be one variant of solution 4 (CRUD-functions). As we have on each layer CRUD-functionalities, we could use each layer for database initialization. But we should decide if we generally prefer the data access layer, logic layer, service layer or batch layer. But the higher the layer, the lower the performance.

[hohwille]

In my current project we have official DDL and master-data in src/main/resources/db/migration and testdata in src/test/resources/db/test. For tests we use H2 and the rest is done with the productive DB. The testdata is only for the common things to test and needs to be maintained in SQL with the general data-model & migration stuff. For complex test-data we combine this with additional approaches.