Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

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

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 environment in a real database and the data being accessed is so small that the access time is not a factor, and I am only running a few tests.

Is it still important to create fake data or can I forget the extra coding and skip right to the real thing?

When I said real database I do not mean a production database, I mean a test database, but using a real live DBMS and the same schema as the real database.

like image 304
Sruly Avatar asked Mar 03 '09 18:03

Sruly


People also ask

Should unit tests use real database?

Unit tests should never connect to a database.

Should I use in memory database for testing?

While some users use the in-memory database for testing, this is generally discouraged; the SQLite provider in in-memory mode is a more appropriate test replacement for relational databases.

Should you test live database?

Live database generally means a read/write based production database. That means your test could interfere with the performance of whatever it serves. Generally you'd do tests in a QA server using a replicated database.

Should you mock a database?

The purpose of unit testing is to verify the database-related code works and mocking the database would hinder the test. Mocking does indeed become useful when testing the business code. You can mock your database calls to return test data and verify the behavior of business logic in those circumstances.


2 Answers

As far as the Real DB does not get in your way, and you can go faster that way, I would be pragmatic and go for it.

In unit-test, the "test" is more important than the "unit".

like image 90
philant Avatar answered Sep 23 '22 20:09

philant


The reasons to use fake data instead of a real DB are:

  1. Speed. If your tests are slow you aren't going to run them. Mocking the DB can make your tests run much faster than they otherwise might.
  2. Control. Your tests need to be the sole source of your test data. When you use fake data, your tests choose which fakes you will be using. So there is no chance that your tests are spoiled because someone left the DB in an unfamiliar state.
  3. Order Independence. We want our tests to be runnable in any order at all. The input of one test should not depend on the output of another. When your tests control the test data, the tests can be independent of each other.
  4. Environment Independence. Your tests should be runnable in any environment. You should be able to run them while on the train, or in a plane, or at home, or at work. They should not depend on external services. When you use fake data, you don't need an external DB.

Now, if you are building a small little application, and by using a real DB (like MySQL) you can achieve the above goals, then by all means use the DB. I do. But make no mistake, as your application grows you will eventually be faced with the need to mock out the DB. That's OK, do it when you need to. YAGNI. Just make sure you DO do it WHEN you need to. If you let it go, you'll pay.

like image 27
Uncle Bob Avatar answered Sep 21 '22 20:09

Uncle Bob