• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • Paul Clapham
  • Devaka Cooray
  • Bear Bibeault
Sheriffs:
  • Junilu Lacar
  • Knute Snortum
  • Liutauras Vilda
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Piet Souris
Bartenders:
  • salvin francis
  • Carey Brown
  • Frits Walraven

December 2003 Journal Article - Unit Testing Database Code

 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
In his inaugural JavaRanch Journal article, Lasse Koskela shares some good advice on unit testing database code and provides a primer on using mock objects to help.
Any comments on the article?
[ December 30, 2003: Message edited by: Lasse Koskela ]
 
Ranch Hand
Posts: 775
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The article is a good example of how to take something with integration complexities and factor our the integration point in order to enable unit testing.
On the other hand, you have to pay attention to how much bang you got out of the tests themselves. Testing against a database is really an integration test, not a unit test. Integration tests that factor out the integration point tend to result in unit tests that don't do much. You can see that in each of the tests examples until you get to the last one (the 'sandbox' approach as he calls it), using dbUnit. It has some meat to it, but that is because it has shifted back into the integration test space again.
Factoring out integration points is more valuable for constructing unit tests of the things that call DAOs, not as much for testing DAOs themselves. If your DAO has enough logic in it to warrant a true unit test, then you've probably got a cohesion problem (stuff in the DAO class that probably doesn't belong there). The only way I know of to get around the integration-tests-without-integration-points-aren't-valuable-unit-tests problem is to switch from mock objects to simulators. For example, you could create a database connection simulator that would parse the SQL in the statements to let you know if it was syntactically correct and had the right number of bind parameters. Mock objects (deliberately) don't have that level of smarts.
[ December 30, 2003: Message edited by: Reid M. Pinchback ]
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reid's point about the need of unit testing database code at all is valid. I had a sentence or two about exactly that dilemma, but had apparently edited it away. Regardless of this, I have found it valuable to have tests to keep those PreparedStatement variables in check.
Thanks for the feedback!
 
You had your fun. Now it's time to go to jail. Thanks for your help tiny ad.
Java file APIs (DOC, XLS, PDF, and many more)
https://products.aspose.com/total/java
    Bookmark Topic Watch Topic
  • New Topic