Unit testing on code that uses the Database [closed]

Answer 1

We do a few tricks:

edit: We do have seperate databases per user. Our buildserver also has it's own database. The cost of extra harddisks is much less than the cost of developers influencing eachother's tests.

1. Our application can generate tables and do upgrade steps itself (no seperate db scripts). This helps our customer, because he only needs to drop in a WAR file and he's done. The application looks at the database and carries out any DDL statements needed before starting up the rest of the Spring context.
2. Our test-suite has some code which unloads the Spring context, drops the database, and restarts the context with a clean database. We can optionally switch this off if we like
3. All our database/SQL unittests are Spring transactional integration tests. This means that after the test is done, the transactions are rolled back, and other unittests will again look at a clean database.

In addition to this all, we try to do mock testing as much as possible, because unittests are really not intended to be integration tests. So try to seperate your servicelayer from the DAO layer. This also helps you find problems more easily because you isolated everything.

At some point I do believe you need to access the database, because it's not an ideal/academic world we live in :-)

Answer 2

here is a good screen cast on this topic called The Value of Small Tests

Answer 3

In reality, you should do both. When you say "build database stub", that hints at mocking in unit tests. And when you talk about "Install a QA database (known-starting point)", that hints at integration tests where you actually hit the database. Unit tests come much earlier in the game and are where mocking comes into play. Mocking is much faster than actually hitting the database. So when you run many unit tests, mocking will save much time. Rhino Mocks is a great framework that I've used personally. But there are several mocking frameworks, find the one that works best for you.

At some point you should put your full database through integration tests, and the best way I've found for that is to have a script that completely creates and populates the database with a known set of data. Then make sure that nothing is going to touch your newly created database except for the integration tests, and test away.

Answer 4

If you're using NHibernate, you can very easily test against an in-memory SQLite database, which is very fast.

Answer 5

The "database stub" that stands in is usually referred to as a "fake repository" or "mock repository". They are a good idea. You can code them by hand (not hard for simple cases) or use a framework like Rhino Mocks to generate them. You don't mention what language you are working in. Rhino mocks is for .Net .

If you use mock repositories then you can run tests against code that works with data, without actually using a database for the data. This makes the tests run very fast, which is a good thing.

Of course, you still have to test the real repository at some stage, and this is more of an issue. These tests will run slower, because they use a real database. Some would classify then as "integration tests" not unit tests because of the speed and dependency issues.

I don't mind what you call them so much, but it's a good idea to keep these tests separate.

A good idea here for data consistency is to begin a db transaction before your test, and roll it back afterwards. That way the database state is reverted to what it was before the test.

Answer 6

We are moving towards using mock frameworks - they mock resources like databases, configuration files etc. Using these frameworks is a practical way to run your unit tests effectively.

One of the frameworks that we are working on is Rhino Mocks. You can read about it in the link below. It also has a good introduction of why you need such frameworks.

http://weblogs.asp.net/stephenwalther/archive/2008/03/22/tdd-introduction-to-rhino-mocks.aspx