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

One advantage of fake repositories is that your regression / unit testing is consistent since you can expect the same results for the same queries. This makes it easier to build certain unit tests.

There are several disadvantages if your code (if not read-query only) modifies data: - If you have an error in your code (which is probably why you're testing), you could end up breaking the production database. Even if you didn't break it. - if the production database changes over time and especially while your code is executing, you may lose track of the test materials that you added and have a hard time later cleaning it out of the database. - Production queries from other systems accessing the database may treat your test data as real data and this can corrupt results of important business processes somewhere down the road. For example, even if you marked your data with a certain flag or prefix, can you assure that anyone accessing the database will adhere to this schema?

Also, some databases are regulated by privacy laws, so depending on your contract and who owns the main DB, you may or may not be legally allowed to access real data.

If you need to run on a production database, I would recommend running on a copy which you can easily create during of-peak hours.