I actually have an article coming out on IBM developerWorks in May on testing just such a situation. :) The short answer is to use AspectJ to replace certain calls (for instance, to your EjbUtil class) when running tests. The article runs a test suite in Cactus that I'm eventually going to work into one of the sample applications. If you're interested, you can start by checking out:
http://www.aspectj.org or http://www-106.ibm.com/developerworks/library/j-aspectj/index.html I'm kind of amused by reading your code, it looks almost exactly like some code I've written, right down to: HandlerHome home = EjbUtil.lookupHome(Handler.class, jndiName); I think our static class is called EJBUtils, and the order of parameters is reversed :) Cheers, Nicholas Lesiecki Principal Software Engineer eBlox, Inc. (520) 615-9345 x104 Check out my new book!: Java Tools for Extreme Programming: Mastering Open Source Tools, including Ant, JUnit, and Cactus http://www.amazon.com/exec/obidos/ASIN/047120708X/ Check out my article on AspectJ: http://www-106.ibm.com/developerworks/library/j-aspectj/index.html -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 24, 2002 9:50 AM To: Cactus Mailing List Subject: Refactoring question Hi, We're building a servlet which receives some parameters as input and calls a handler based on the input parameters. How that works is that one of the parameters is used as the JNDI name of the home interface of the handler. We pass that parameter to a static utility method which will return the home interface of that handler. So something like this: String jndiName = httpRequest.getParameter("name"); HandlerHome home = EjbUtil.lookupHome(Handler.class, jndiName); Handler handler = home.create(); Response response = handler.execute(); httpResponse.print(response.toString()); . . . or something similar to this. All this nice stuff is going on in the servlet's service() method. So evidently, it's untestable unless you have the whole container running. In order to test properly, there needs to be a refactoring of the service method so that I can write a test for it specifically, without needing to have a container running that will give me the correct home for the handler and all the rest of that. Has anyone done anything similar? What type of refactoring did you do? I think the main problem in this case is the Handler. The name of the handler associated with each JNDI name is defined in the deployment descriptor for the application. Is my option, then, to modify the deployment descriptior on the fly (a bit like it's explained in the FAQ for web.xml) and to create a stubbed handler just for testing purposes? Or is there a more obvious way to do this that I can't see? Thanks for all the help, L (who will eventually contribute back) -- Laurent Duperval <mailto:[EMAIL PROTECTED]> Do you need a silencer if you are going to shoot a mime? -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
