Why not hit the database inside unit tests?

Question

I\'ve read in blogs that the database should not be hit when the unit tests run. I understand the theory, however say i have complex store procedures that are part of a busi

Answer 1

You are simply in a semantic grey area.

• System tests cover the whole system from end-to-end.
• Unit tests can be used to describe a sub-segment of the end-to-end cycle.

In that case your unit tests of your application code would/might not hit the database, but you would/might have unit tests that covered your database stored procedures...

Basically divide your application into things to be tested along partitions that make sense. If you choose the wrong partition line you end up with a big code maintenance problem with mock objects and test scaffolding and stuff...

A common way with web apps is to write a series of unit tests that test the data access layer...

Then write a series of unit tests that test the application layer (including the data layer) ...

And finally write some browser-based system tests...

The trick is to only put information in and out of the middle set - the application layer - through the API and not burrow into the database to see if something worked. That way your tests won't break if you change the data schema.

But sometimes (as I actually currently doing as I write this) you HAVE to look into the database to make a meaningful and robust test suite (I am testing server-server transfer protocols).

Focus on the way that gets maximum code coverage and stability for your application, whilst writing the least amount of testing scaffolding, and avoiding brittleness in your test suite.