Introducing StrutsTestCase
StrutsTestCase
is an open source project from SourceForge, which extends
the JUnit framework to allow testing the Action class.
It even offers two approaches: one that uses the servlet
container employing the Cactus
framework from Jakarta, and one that simulates the
container. This article will explain how to use the simulated
set-up, or the "mock object approach".
The idea behind the StrutsTestCase (STC) framework is that
it's not you that calls the execute method, but
STC. So it's up to STC to supply the four parameters to
the execute method, and when you use the mock object
approach, these parameters will be simulated. The request
and response objects don't come from a servlet container,
they're set-up by STC. The mapping and form
parameters however, are created by STC by reading the struts-
config file.
One of the things you'll soon get curious about is how well
STC can simulate the request and response objects. The answer
is: pretty well, but it doesn't do the job 100% perfectly. We'll
revert to this topic later.
Let's have a look at a simple STC testprogram:
Listing 1: A StrutsTestCase program
package hansen.playground;
import servletunit.struts.*;
public class TestStrutsAction extends MockStrutsTestCase {
public void setUp() throws Exception { super.setUp(); }
public void tearDown() throws Exception { super.tearDown(); }
public TestStrutsAction(String testName) { super(testName); }
public void testList() {
setRequestPathInfo("/list");
actionPerform();
verifyForward("list");
verifyNoActionErrors();
}
public static void main(String[] args) {
junit.textui.TestRunner.run(TestStrutsAction.class);
}
}
|
The class structure will be familiar to JUnit users:
- the setUp and tearDown methods are called
before and after every test method respectively in the
class
- every method that's supposed to test something must have a
name starting with "test"
- the main
method calls one of the three TestRunner interfaces
MockStrutsTestCase extends JUnit's TestCase class, so all of
the "assert" methods from JUnit are available in the
test methods.
What's not familiar are the four statements
in the testList method. Let's have a closer look at
them:
| statement |
purpose |
setRequestPathInfo("/list")
|
tells STC that we want to test the "list" action
defined in struts-config. Note that struts-config contains the information
about which class to call |
actionPerform()
|
tells STC to make the call to the execute
method |
verifyForward("list")
|
tells STC to verify that a forward to the name
"list" was attempted. "list" is also defined in
struts-config |
verifyNoActionErrors()
|
tells STC to verify that the execute method didn't
create any ActionError objects. |
The snippet from the struts-config file could look like this:
<action path="/list"
type="hansen.playground.ListDVDAction">
<forward name="list" path="/list.jsp"/>
</action>
|
I hope you appreciate the simplicity of the STC set-up. It's
no big deal to get started testing your Struts actions, so what
we need now is a Struts application and a download of STC. Let's
take the application first.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
