This is a common enough problem with JNDI. Unfortunately, JNDI was not designed in a particularly testable way.
To solve this sort of problem I wrote a simple (and, as it happens, very fast) in-memory JNDI implementation which can be started up in a test case and populated with whatever objects you need. It took me about a week to get it implemented and working properly (some of the semantics of the JNDI calls are a bit strange). To use it, just set the JNDI initialization classname parameter to the name of your IntialContextFactory implementation rather than the one to be used for the live deployment.
You could either have a go at writing one yourself, or find one someone else has written. If you want to read/use mine it's available in
my "stringtree" project in the package org.stringtree.jndi. There's just three source files. Presumably some other people have done implementations, too.