databasejunitschemarecreate

Why is recommended to recreate the whole database schema for each test?


Its said that in order to execute database tests with Spring data(JPA) for example, its a good practice to recreate the whole database schema for each test in order to drop all the objects from database after the test and clean the whole environment for the next test (https://reflectoring.io/spring-boot-data-jpa-test/). But according to the question I made (Sql scripts for creation of same table in repository tests), if its recommended to create the whole schema for the database for tests and not just a part of it, why not to reuse this schema for all tests if they share the same schema and delete just the data?

Thanks


Solution

  • The whole point is to make sure that your tests are isolated and data required or generated by a test, won't affect the result of a different test.

    Re-creating the schema gives you this guarantee because each tests will start with a clean database.

    That said, the creation/drop of the schema is a pretty heavy operation, and the more tests you add to the test suite, the slower it will become. The drawback is that you need to make sure that the data is cleaned after each test. This might not be too complicated to achieve in practice (you might need to pay special attention about different entities in different tests mapping to table with the same name) but if you are working an a small project or your database is really quick updating the schema, it might not be worth the hassle.

    It's up to you to decide what works for your project.

    As a practical example, in Hibernate Reactive we need to run the same tests on several different databases. We started re-creating the factory for each unit test, but because running tests was becoming too slow (especially on some databases), we've switched to re-creating the factory once for each test class. It helped us to save a lot of time because tests in the same class became so much faster.

    In the end, you need to decide how your test suite is organised and the benefits of one approach over the other. But as long as you are reasonably sure that the tests won't affect each other, you can use the solution you prefer.