aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Unit Testing Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Unit Testing" Watch "Unit Testing" New topic
Author

Unit Testing

Steve Chernyak
Ranch Hand

Joined: Oct 19, 2000
Posts: 113
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
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Steve Chernyak
Ranch Hand

Joined: Oct 19, 2000
Posts: 113
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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
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.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Unit Testing