• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

is there any way to unit test JDBC code without connecting to databas?

 
Ranch Hand
Posts: 551
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi
Thank you for reading my post.
Is there any way to unit test JDBC code without connecting to database?
Thanks
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can use HSQLDB with an in-memory database; that way, not even a file is created, which is handy for testing.
 
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm using JUnit attaching to an in-memory instance of Derby.

The production system uses DB2, and there are a few cases where the difference between DB2 and Derby cannot be unit-tested, but overall it works well.

JUnit can also roll back changes after a test so even if you use a permanent database for testing, the tests can be made to run from a consistent baseline instead of continuously polluting the test database.
 
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
This may just be semantics, but I wouldn't consider any test that needs a database (in memory or on disk) a unit test. I'd call it an integration test.
 
Tim Holloway
Saloon Keeper
Posts: 27762
196
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, the database unit testing that I do is testing individual DAOs at the lower level and individual business services at the higher level, so I'd consider them as units.

The fact that they need to invoke (or mock) external services is sort of beside the point, since I'm not testing the services themselves, which are tested as units at lower levels.

I'm VERY keen on DAO unit-testing, though, since SQL is an interpreted language and thus isn't validated at compile-time, but I don't want to set up a complex framework for testing the database layers, since not only is it more work, it has a higher risk of having unrelated problems obscure or interfering with what I'm actually attempting to test. So I use the database to serve as the validator.
 
Gregg Bolinger
Ranch Hand
Posts: 15304
6
Mac OS X IntelliJ IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ah, you said the key work there: Mock.

I get what you're saying though. Like I said, semantics. I'll back track on my in-memory being an integration test and concede that unit testing is still appropriate given that you're asserting SQL.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic