• 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

Unit Testing

 
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have a DAO object that i would like to write unit tests for. This object depends on a ServiceLocator object to get a DataSource instance. The DataSource instance is retrieved by:

Which works fine if the code is deployed to an AppServer.
How can I write my test cases for the DAO or any classes that depend on the DAO without starting up the application server?
I am assuming there is no way to test the ServiceLocator without an App Server. Is this right?
My idea was to extend these classes and mock return values that are coming back from ServiceLocator as well as the data from the DataSource. This would require me changing my private methods to protected which I don't really want to do just for sake of tests. Is there a better way?
Thanks
 
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can you not create the Context outside the object and pass it in?
That way you can pass in a fresh InitialContext in your app server, or a locally-created one in your tests.
 
Steve Chernyak
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Frank,
Im still not clear on how I would run the tests without having the appserver started.
Should I be providing my own "dummy" implementations of these classes (Context, DataSource, Connection)?
Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Steve Chernyak:
I have a DAO object that i would like to write unit tests for.


Though I don't know much about DAO, I will try to give some rather general advice. Please pardon me if those don't apply to your situation...


How can I write my test cases for the DAO or any classes that depend on the DAO without starting up the application server?


An important step probably would be to make your DAO classes as dumb as possible, so that they don't need many tests. Additionally put a thin layer between the DAO implementation and the rest of the system, so that the tests for your business logic don't need to depend on the presence of DAO at all.
Of course you might still want to write some tests for the DAO layer, so...


My idea was to extend these classes and mock return values that are coming back from ServiceLocator as well as the data from the DataSource. This would require me changing my private methods to protected which I don't really want to do just for sake of tests. Is there a better way?


I wouldn't hesitate to make those methods protected. IMO, access privileges are way overrated and much less important than appropriate testing. YMMV, of course.
 
Frank Carver
Sheriff
Posts: 7001
6
Eclipse IDE Python C++ Debian Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Im still not clear on how I would run the tests without having the appserver started.
Should I be providing my own "dummy" implementations of these classes (Context, DataSource, Connection)?

Depending on what you want to do with your tests, you may need Context. When you actually look at it, JNDI is really a simple interface, and I wrote a complete "in-memory" JNDI implementation for testing this sort of thing in a couple of hours. If I find it again, I'll put it up on the web.
If you want to test how your DAO interacts with the database, why not use one of the many simple, pure Java databases (hypersonic sql is a good example). Set up your minimum test data locally, then pop a DataSource for that database in your in-memory JNDI repository and run your DAO.
All under control of your test runner.
This has the advantage that you can test the real DB behaviour of your DAO, on both correct and faulty data, without any external dependencies at all.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic