Is it bad practice to run tests on a database instead of on fake repositories?

Question

I know what the advantages are and I use fake data when I am working with more complex systems.

What if I am developing something simple and I can easily set up my e

Answer 1

It sort of depends what you want to test. Often you want to test the actual logic in your code not the data in the database, so setting up a complete database just to run your tests is a waste of time.

Also consider the amount of work that goes into maintaining your tests and testdatabase. Testing your code with a database often means your are testing your application as a whole instead of the different parts in isolation. This often result in a lot of work keeping both the database and tests in sync.

And the last problem is that the test should run in isolation so each test should either run on its own version of the database or leave it in exactly the same state as it was before the test ran. This includes the state after a failed test.

Having said that, if you really want to test on your database you can. There are tools that help setting up and tearing down a database, like dbunit.

I've seen people trying to create unit test like this, but almost always it turns out to be much more work then it is actually worth. Most abandoned it halfway during the project, most abandoning ttd completely during the project, thinking the experience transfer to unit testing in general.

So I would recommend keeping tests simple and isolated and encapsulate your code good enough it becomes possible to test your code in isolation.