My application has big integration with the database. Classes that use the database are very crucial for the system, so I write small unit tests for classes that I call
Repository. The reason behind the unit-testing database operations are for example verification of caching or correct order of query execution (to avoid foreign key constraints etc). Plus, I write these tests before the actual code since it allows me to work faster.
For unit testing these operations, I use an in-memory database (H2Database - Java). However, since the schema of the database is quite big, creating the schema in the in-memory database takes about ~4 seconds. For hundreds of unit tests such these, this will make my unit-test suite quite slow.
In order to make it faster, instead of erasing completely the in-memory database between tests, I just truncate all the tables from it and not re-create the schema from scratch. This runs quite faster. Truncation takes about 5-10ms and the database is statically shared across all unit tests. This way, 1 test takes 4 seconds. 100 tests take 5 seconds.
But, (to me) that means that this in-memory database/connection is an important part of the test suite. If this does not work correct, I might end up with wrong feedback from my actual tests. So, in the end, I wrote some unit tests that verify the behavior of the test-database. For example, that all tables are truncated every time you call
The fact I wrote "tests" for the test code, is it a smell? Is it a wrong decision to do? I know that since it gives me confidence, it should be alright. But... is it? Or it is unnecessary thing to do?
There is always the option to create between the tests only the parts of the schema I need. But this comes with one disadvantage. All the
CREATE TABLE statements in my unit tests are reducing readability and tests are full of noise. Having the schema as a whole in an
sql file and then running it, is more convenient and easier to maintain instead of breaking it into pieces here and there.