Granny's Programming Pearls
"inside of every large program is a small program struggling to get out"
The moose likes Testing and the fly likes Testing data access classes and entity beans Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Head First Android this week in the Android forum!
JavaRanch » Java Forums » Engineering » Testing
Bookmark "Testing data access classes and entity beans" Watch "Testing data access classes and entity beans" New topic

Testing data access classes and entity beans

Allan Halme
Ranch Hand

Joined: Aug 22, 2003
Posts: 62
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)
Vincent Massol
Ranch Hand

Joined: Aug 09, 2003
Posts: 70
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="" target="_blank" rel="nofollow">JUnit in Action</a> author
Allan Halme
Ranch Hand

Joined: Aug 22, 2003
Posts: 62
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 ]
Jeanne Boyarsky
author & internet detective

Joined: May 26, 2003
Posts: 32301

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.

[OCA 8 book] [Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Allan Halme
Ranch Hand

Joined: Aug 22, 2003
Posts: 62
Sounds good. I'll look into MockObjects.
I agree. Here's the link:
subject: Testing data access classes and entity beans
jQuery in Action, 3rd edition