A while ago I described how to easily test
controls in the Workshop IDE. Since then there's been no shortage of
people asking how to test controls that rely on a J2EE container. It usually comes
in the form of the question "How do I test a service control?"
There are several approaches you can take to this problem. One way would be to
front it with a web service, page flow, or servlet and use the existing JUnit extensions
for these technologies. Another option, and the one I'll describe here, is to use
Cactus.
The good news is that WTP (and thus Workshop) comes with built-in Cactus integration.
This allows you to run ServletTestCases right in the IDE along with your other tests
and get the results in the JUnit results view, etc. But there are a couple of tricks
you'll need to know to use it with a service control.
For a tutorial on the basic WTP and Cactus integration (which I won't re-hash here)
see this
article on the WTP website. Beware that the article is a little dated. In particular
you don't need to manually add the jars to the build path, just dropping them in
WEB-INF/lib will take care of that for you.
The first trick to know about is that you need to change the JRE on your project
to point to the Sun VM instead of JRockit. This is because Cactus actually has an
invalid attribute in one of its class files that the Sun VM doesn't try to validate,
but JRockit (correctly) does. This will manifest itself as a ClassFormatError similar
to:
java.lang.ClassFormatError: org.apache.cactus.internal.configuration.ConfigurationInitializer
I'm told that JRockit may have a "fix" for this in a future release,
but for now the easiest way to get around this is to use the Sun VM for Cactus tests.
I believe it's just an issue with how it was compiled--not a source issue. If you
want to continue using JRockit for the tests you may also be able to recompile the
Cactus source, but that's an exercise left for the reader.
You can change the JRE by right-clicking the JRE System Library container on the
project, selecting Configure, and selecting "jdk150_06".
The next step is to make your TestCase class. You've got two options here. You
can subclass ServletTestClass and instantiate the service control programmatically.
An example of that might look like:
@ControlReferences({TestServiceControl.class})
public class SimpleTestCase extends ServletTestCase {
public void testServiceControl() throws ClassNotFoundException {
TestServiceControl myControl = (TestServiceControl) Controls.instantiate(
getClass().getClassLoader(), "controls.TestServiceControlBean", null);
String string = myControl.saySomething("hi");
assertEquals("say hi",string);
}
}
Notice that this snippet uses a @ControlReferences annotation. This is necessary
because the service control uses assembly, and @Control and @ControlReferences are
the two annotations that trigger assembly. Since this snippet instantiates the control
programmatically and thus does not use @Control, without @ControlReferences it won't
have the artifacts it needs at runtime and will fail.
The other option is to subclass ControlTestCase as described in my
earlier post and wrap it with Cactus' ServletTestSuite. This approach is my
preferred approach since you get all the benefits of the declarative instantiation
and injection. And it's just cleaner. Note that this approach no longer requires
the @ControlReferences annotation.
public class ControlTestCaseCactusWrapper
extends ControlTestCase {
@Control
TestServiceControl testServiceControl;
public void testControl() {
String string = testServiceControl.saySomething("hi");
assertEquals("say hi",string);
}
public static Test suite()
{
ServletTestSuite suite = new ServletTestSuite();
suite.addTestSuite(ControlTestCaseCactusWrapper.class);
return suite;
}
}
If you try to run your test with Run on Server now you'll probably see an error
like:
java.lang.NoClassDefFoundError: weblogic/logging/LogEntry
What's happening is that Cactus is going through commons-logging, and Workshop
installs a nice bridge that integrates commons-logging with the WebLogic logging
infrastructure. In this case that logging infrastructure doesn't end up on the classpath
(because of some quirkiness around how Cactus works). Again, you've got two options.
One is to put weblogic.jar onto the project classpath. You can do this by going
to Windows > Preferences > Server > Installed Runtimes > BEA WebLogic
v9.2. On this screen is an option to put weblogic.jar on the classpath instead of
wls-api.jar.
Normally we really don't recommend this because it can slow down your IDE
(lots more classes to sift through) and because it makes it easier to take dependencies
on non-API classes. So be careful to stay within the documented API if you take
this approach.
The alternative is to disable the logging bridge for your tests. This is done by
modifying the commons-logging.properties file in your project (usually in WebContent/WEB-INF/classes
or EarContent/APP-INF/classes). Just comment out the line or change it to point
to a different LogFactory so it will no longer look for the WLS classes. You probably
want to do this only for your tests; make sure this bridge is still enabled when
you're deploying and running your application.
And that should be it. At this point you should be able to right-click your test
case and select Run on Server (make sure you choose this instead of Run As JUnit
Test) and get the integration with the IDE's JUnit view, etc.
]]>
