What's the verdict on the value of testing data access classes and entity beans? On the one hand, they're pretty straightforward and I can easily imagine an argument against having unit tests that (merely) set up some test data in a database, then call the DA to insert/update/delete, and assert on the resulting state of the database. On the other hand, though, I have personally come across DAs and entity beans that fail in their simple task, and where a decent unit test would have caught it. Personally, I write these simple unit tests because of the warm comfy feeling they give me about my code (this feeling is what Beck preaches, iirc). I'm interested in arguments against? PS. I don't, however, particularly see value in testing value objects and their accessors (ie that take a bunch of data in the constructor or through setters and hand it back out through getters) -- these should get effectively tested via unit tests for other code that uses them. [ November 06, 2003: Message edited by: Allan Halme ]
<i>The lyf so short, the craft so long to lerne.</i> --Geoffrey Chaucer (c. 1343-1400)
Hi Allan, First it depends on whether there is lots of code logic in your DA objects or if it's simply a conversion ResultSet --> java objects. If you have logic, it's probably better to put in a higher level place. My feeling is that DA are best tested in integration, either with functional tests or with a tool like Dbunit and/or Cactus. Of course this raises the issues of database data but this is a good thing as you'll need to sort this out anyway before you can do functional/acceptance tests.
-Vincent<br /><a href="http://www.manning.com/massol" target="_blank" rel="nofollow">JUnit in Action</a> author
Joined: Aug 22, 2003
Yep, I've got DbUnit in place for straightforward testing of data access classes. Just coded a new test where I set up test data in the DbUnit dataset file, then I confirm that it is successfully retrieved by my DA class. A trivial, straightforward test, but it gives me a good comfortable feeling. We'll also be using DbUnit to insert test data into our database when doing higher-level unit tests on our business logic. Of course, wherever and whenever we decide on using mock objects to unit test our logic, then that will mostly do away with the need to set up test data in the database. [ November 06, 2003: Message edited by: Allan Halme ]
Allan, I've started writing MockObject unit tests for my data access classes. The MockObject project provides mocks for the prepared statement, result set, connection, ... This helps me spot null pointers and other things that aren't always easy to set up in the data. I also test the interaction with the database through real calls.