EricHolsinger.com

Icon

This is where you get the spin on Eric Holsinger.

JUnit Testing JNDI Datasources: Thinking outside of the Container

java programming tipsOne of the problems with using a JNDI Datasource is Unit Testing outside of the container. Testing in the container is a pain and it’s slow if you are fixing bugs or just testing to make sure what you have works after a few changes. It’s OK for system tests.

Another option might be to have one set of configuration for the container and one for Unit Testing. An example might be to have two files controlled by your classpath or even worse, one file which you comment/uncomment to get the datasource you need. Then hope you package up the right configuration for the release.

What you really need a fast way to test outside of the container without changing all of your configuration just because your testing. Thankfully, spring provides a nice way to test your application outside of the container. Just bind your resource to a SimpleNamingContext mock and voila!

You may have found Rod Johnson’s simple forum post saying just that: Problem running JUNIT test with JNDI datasource.

If you found yourself looking for a little bit more explanation, here it is.

This example uses Spring 1.2.7 and JDK 1.4. You’ll have to write your own JDBC datasource bean definition for whatever database you are using. But, here is an example snippet from a unit test which binds a local JDBC datasource to a JNDI mock for testing.

 

import javax.sql.DataSource;

import junit.framework.TestCase;

import org.springframework.context.support.ClassPathXmlApplicationContext;

import org.springframework.mock.jndi.SimpleNamingContextBuilder;
public class JndiTest extends TestCase {

	private static String[] springFiles = { "beans/my-beans-config.xml" };

	private ClassPathXmlApplicationContext context;

	public void testJndi( ) throws Exception {

		context = new ClassPathXmlApplicationContext(springFiles);

		SimpleNamingContextBuilder builder =

			SimpleNamingContextBuilder.emptyActivatedContextBuilder();

		DataSource ds = (DataSource) context.getBean("dataSource");

		builder.bind("jndi:jdbc/DataSource", ds);

		// your dataSource bean is available as "jndi:jdbc/DataSource", now

	}

}

You’ll need a few jars to make that work. In my case, I needed:

  • junit
  • spring
  • spring-mock
  • commons-logging
  • log4j
  • commons-pool
  • commons-dbcp
  • your favorite database jar

I hope that helps!

If you enjoyed this post, make sure you subscribe to my RSS feed!

 

 

Disclosure: All of the products and services discussed on this site were purchased by myself, unless otherwise noted. Affiliate links are sometimes included in the posts. I generally don't get freebies to review or get paid to review things (outside of affiliate links). If I get it for free, I'll tell you. Material compensation does not influence my opinion and my views are my own.

 

Category: Programming

Tagged:

Viewed:28,366

One Response

  1. the link to the post by Rod Johnson is broken. The working link is: http://forum.springsource.org/showthread.php?t=16670

    Cheers

Leave a Reply

Contact Information

Eric Holsinger
Saco, ME 04072
ph: 207 . 749 . 1703
eM: eric.holsinger@gmail.com
My company: Whirlidoo, LLC

View Eric Holsinger's profile on LinkedIn

Categories

My Twitter noise...

  • Am I the only one who thinks coffee from a French press tastes like coffee with little tiny coffee grounds all over my tongue? 9 hrs ago
  • “@ADAMATOMIC: APIs with weird, made-up names sure make googling for assistance VASTLY easier than using SUPER common words like "air"...” 9 hrs ago
  • Coding can be such an emotional roller coaster... 1 day ago
  • More updates...

Posting tweet...

Powered by Twitter Tools


Banner