This week's book giveaway is in the Cloud forum.
We're giving away four copies of Terraform in Action and have Scott Winkler on-line!
See this thread for details.
Win a copy of Terraform in Action this week in the Cloud forum!
  • 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:
  • Tim Cooke
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Jesse Silverman
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
Bartenders:
  • Piet Souris
  • Al Hobbs
  • salvin francis

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: 6920
  • 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: 6920
  • 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.
 
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
reply
    Bookmark Topic Watch Topic
  • New Topic