Unit test DAO without the Database

[browncoat]

I am having a VERY hard time finding a thread in this forum that covers this issue in a clear way. Here's what I want to do.

I have a bunch of DAOImpl objects using SJDBC that all implement DAO interfaces. These DAOs are very simple. Each method contains an SQL statement which we call on our database and then use either a RowMapper object or a RowCallbackHandler to map the rows to a Pojo which is returned to whatever Service is calling teh DAO.

I want to be able to use JUnit to test this DAO WITHOUT connecting to ANY database, even an in-memory database (so no HSQLDB!). This is because I don't care about unit testing the database. If the database is broken, there's nothing I can do about it. In my opinion, DAOs do 2 things; 1) call a SQL statement, 2) map the results to POJOs to be returned. I can't EVER guarantee the DB is going to behave the way I want, so I don't want to waste my time writing tests for the DB working properly. I just want to test that IF the DB does behave properly that my DAO does teh appropriate stuff.

What have people done to accomplish this? I've considered using mocks but what do I mock? Every DAO contains a DataSource and connects to it. So I have 3 main questions:

1) How to I pass a mock DataSource so my test doesn't actually try to connect to some real database?

2)Once I do, how do I populate the JdbcTemplate with fake data to be mapped when calling processRow()?

3) Am I taking a totally stupid approach to accomplishing my goals?

Any feedback would help a TON! This has been the source of great distress with us. We want to use TDD in our process, but so far our DAO tests have all SUCKED! (Sorry to be blunt, but our team is very frustrated). Please help us!!! Just please remember that any advice must meet the following criteria: it must be testing the DAO, NOT jdbc; 2 it must not rely on any database truly existing.

Thanks

[wpoitras]

I use MockRunner for writing unit tests for DAOs. MockRunner has an API that allows you to specify what result sets, output parameters, etc get passed back when certain SQL is called. You can either get it to return different result sets based not only SQL but input parameters.

I tend to initialize my DAOs in my unit tests something like this:

  /* Do the mock runner stuff */
  DataSource ds = /* call mock runner factory to get datasource */
  MyDaoImpl dao = new MyDaoImpl();
  dao.setDataSource(ds);
  dao.afterPropertiesSet();

I don't have any of my examples in front of me. But the examples on their site should give you an idea.

[too_many_details]

Hi,

what i do when i dont have a db (or don't want to use one for quick testing) is to create another DAO Impl class and use that.

In your case, when running tests, use the DAOTestImpl class that returns the POJOs you want (either hard coded or easily generated based on any params going in). Thats is NO JDBC is used.

Not really convinced there is any point testing the jdbc code (getting a result set and creating your POJOs) without a db. On the other hand, testing your business layer without the hassle of having a db (and getting hard-coded POJOs from the test DAO class) seems useful.

Hope that helps

Rakesh

[browncoat]

Thanks to both of you. I'll check out mockRunner and see if that helps.

[wpoitras]

Not really convinced there is any point testing the jdbc code (getting a result set and creating your POJOs) without a db. On the other hand, testing your business layer without the hassle of having a db (and getting hard-coded POJOs from the test DAO class) seems useful.

I recently found it useful for creating simple boundry cases for some of my JDBC code to make sure it works properly. Especially when your data doesn't map directly to a simple domain object.

[jasonk]

A little belated, but I might suggest this:

http://www.bluedevel.com/blog/?p=12