views:

2063

answers:

9

I'd like to write some unit tests for some code that connects to a database, runs one or more queries, and then processes the results. (Without actually using a database)

Another developer here wrote our own DataSource, Connection, Statement, PreparedStatement, and ResultSet implementation that will return the corresponding objects based on an xml configuration file. (we could use the bogus datasource and just run tests against the result sets it returns).

Are we reinventing the wheel here? Does something like this exist already for unit testing? Are there other / better ways to test jdbc code?

+1  A: 

There is DBUnit. It won't allow you to test your jdbc code without a database, but it seems like you could introduce a different set of buys by emulating a database.

Steve K
+6  A: 

You could use DBUnit together with a HSQLDB which can read its initial data from CSV files for example.

WMR
+4  A: 

That's why you have derby (now called JavaDB) or sqlite -- they are small, simple databases that you can create, load, test against and destroy relatively quickly and simply.

S.Lott
+6  A: 

Use any of the Mock frameworks for such a task. (jMock, etc.)

Some examples

Sunny
A: 

I would say that HSQL is the way to go during your unit tests. The point of your test is to test your jdbc code and make sure it works. Adding custom classes or mocking the jdbc calls can easily hide bugs.

I mostly use mysql and when the tests run the driver class and url is changed to org.hsqldb.jdbcDriver and jdbc:hsqldb:mem:test.

+1  A: 

While the way to mock jdbc in your application is of course dependant on how you've implemented your actual jdbc transactions.

If you're using jdbc as is, I'd assume you have written yourself an utility class of sorts to do some tasks in the line of DBUtils.getMetadataFor(String tablename). What this would mean is that you'd have to create a mock of that class and that could be all you need. This would be rather easy solution for you since you apparently already have a series of jdbc related mock objects available. Note that I'm assuming your jdbc code isn't exploded all around the application - if it is, refactor!!!

If you're however using any framework for database handling (like Spring Framework's JDBC Template classes) you can and should mock the interface class using EasyMock or some other equivalent. That way you can have all the power in the world required for easy mocking of the connection.

And last if nothing else works, you can do what others have said already and use DBUnit and/or derby.

P Arrayah
A: 

@tarken Could you please give somemore inputs on using the tools?

+4  A: 

You have several options:

  • Mock the database with a Mock library, e.g. JMock. The huge drawback of this that your queries and the data will most likely be not tested at all.
  • Use a light weight database for the tests, such as HSQLDB. If your queries are simple, this is probably the easiest way to go.
  • Dedicate a database for the tests. DBUnit is a good option, or if you are using Maven, you can also use the sql-maven-plugin to set up and tear down the database properly (be careful of dependencies between tests). I recommend this option as it will give you the biggest confidence that the queries work properly with your db vendor.

Sometimes it is necessary and useful to make these tests configurable so that these tests are only executed if the database is available. This can be done with e.g. build properties.

Tatu Lahtela
Thanks I like the idea of using maven to setup / tear down the database. We're using maven now for builds so this would be pretty easy for us to use.
ScArcher2
+1  A: 

I prefer using EasyMock for testing a not-so-easy-to-test code.

folone