Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Unit testing database connections in container

 
Bloo Barton
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to create unit tests that are able to work with a DAO that relies on a datasource managed by my web server. I have looked at in container options like Cactus, but I don't see that this handles my need. Has anyone dealt with a similar problem in the past?
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So which unit you want to test -- the DAO or the class that uses a DAO?
 
Bloo Barton
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm trying to unit test the DAO itself. I am able to unit test the other classes with StrutsTestCase.
 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok. So how does this problem of yours exhibit itself? I suppose you get some kind of an exception? Or is it something about transactional boundaries?
 
Bloo Barton
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I get a null exception error since my unit test is not occuring "in container". When the actual application runs, everything is fine. This is not acceptable though, since a unit test is required to show the DAO is working correctly.

So I'm wondering if there is a way to do an in container test on my DAO, or possibly a mock object approach that would replace my container specific data connection with an independant data connection...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It's probably possible to use a mock.

Can you show us the code where the NPE occurs?
 
Bloo Barton
Ranch Hand
Posts: 63
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It fails on the call to getConnection. The code looks like this.



This is the proper way to create the connection when running in JRun. DEVSERVER is a managed datasource that is actually configured in JRun. Then JRun automatically handles pooling and other nifty features...

Since it is handled by JRun it does not exist outside the container and so regular unit tests fail...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instantiate the InitialContext outside of the DAO and pass it in where you initialize the application (for example via the constructor). The test then can pass in a mock Context instead.

Would that work for you?
 
Mike Wislocki
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I also had a similar problem, but got a little further. I can get my initial context, however I fail on the lookup:



In my test case, I must set the context factory in order to get the initial context


The problem I run into now is I get the exception:

[junit] javax.naming.NameNotFoundException: Name java:comp is not bound in this Context

Anyone have any thoughts on this?
-M
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Instead of org.apache.naming.java.javaURLContextFactory use a Mock implementation that is fully under your control and can be made to behave exactly the way you need for the tests.

Google for "mock objects" for more info.
 
Michael Bronshteyn
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Mock objects are great thing, but management people don't always understand what they do. Thus, if they don't see records in the database they may get concerned.

You can try to use local database and use your DAO objects to store and read data there from JUnit test classes. You would need to override the class which gets the connection to the database so you get your local connection. I used this approach for one of my projects and worked fine.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Michael Bronshteyn:
Mock objects are great thing, but management people don't always understand what they do. Thus, if they don't see records in the database they may get concerned.


I don't think that JUnit tests are a very good medium to communicate to business people, anyway. I'd prefer FitNesse in such a case...

You can try to use local database and use your DAO objects to store and read data there from JUnit test classes. You would need to override the class which gets the connection to the database so you get your local connection. I used this approach for one of my projects and worked fine.


The biggest drawback I can see is that such kinds of tests are typically dead slow...
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic