I have recently started using test-driven development and unit testing, and it has paid off immensely in the areas where I have aplied it. One area that it has been helpful in is database access. When I abstract away the data access, the testing of methods that need the data become almost ridiculously easy.

However, I haven't been able to find or figure out a way to test the DAOs themselves. (It would be self-defeating to abstract them out!) A DAO should in theory just move data back and forth between the database and the application; can this be considered too simple to test?

I have experimented with setting up a Derby database on my local machine for tests, but it's difficult to automate starting the server, creating the databases, and creating the tables.

Is there any way to automate testing of data access objects?

4 Answers 4


If you want to automate this sort of testing (I agree with Gary that it's integration rather than unit-testing), have a look at DBunit. It's a framework that allows you to set up a clean database copy for each test, allowing you to run tests against known data in an automated fashion. Combine it with the Hypersonic in-memory database for speed.


Determine what you need to test and then test it

In the case of a typical DAO, it takes some parameters, applies them to form a query, gets the results, perhaps fiddles with them a bit and then returns them.

Obviously, within that list there are lots of opportunities to introduce helper frameworks (in Java this would be Spring templates, Hibernate Query objects and so on). So, look at your DAO, determine how it interacts with other supporting objects, and mock those supporting objects out.

Remember, your test is interested in verifying that the DAO data flow is correct, you're not trying to test that the supporting framework is working (that's the job of their unit tests).

If you find yourself going down the road of creating databases then you're out of unit tests and into integration or functional tests. These are appropriate when you need to test the quality of your queries against representative production datasets.


The whole point of a unit test is to test a single unit of behavior in complete isolation. The whole point of a DAO is to integrate with some external service (database, file system, web service, …)

You simply can't unit test it. Instead, you make it so simple and small and straightforward and "dumb" that it is "obviously correct". Oh, that, and you integration test the youknowwhat out of it, because nothing is ever correct, not matter how obvious it looks.

can this be considered too simple to test

It's not that it's too simple to test, it's that the whole point of a DAO is to work together with other stuffs (technical term :-) ), whereas the purpose of a unit test is to test stuffs in isolation. There are plenty of other kinds of tests (integration tests, functional tests) that can be used to test DAOs, just not unit tests.


One of the mantras of XP is "Test everything that can possibly break". Some people believe that this means that every line of code should be tested.

I however take a more pragmatic approach. If I don't believe that there is a risk that a certain parts of the system would be broken if another developer has been making modifications, then I don't find it necessary to include a test for this, e.g. checking input arguments for null values.

So in your question, if you believe that the code is so simple, that once written, it would not break when someone touches the code, then no, I would not bother to write tests for it.

That said, I would often write tests for it to begin with because that is how I would verify that this module works when writing it to begin with. If you don't have the test, you need to run the entire application to verify that your data access code works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.