Hello. I'm new to cactus and I think it's a wonderful tool ( much thanks ).
After reading this thread, I wanted to ask a struts related question and
pose a suggestion for 1.2 or 2.0.
Firstly,
I've written some cactus tests that test out the perform method of the
struts Action class,
and the first thing I wanted to see was if I was going about it in the
correct fashion.
Below is a code sampling of what I'm doing:
public void testPerform() throws Exception{
config.setInitParameter( "application", "my.com.ApplicationResources" );
//application initParam for ActionServlet
actionServlet = new ActionServlet(); //instance variable declared
elsewhere
actionServlet.init( config );
ActionMapping mapping = actionServlet.findMapping(
"/somepath/somemapping" );
MyAction action = new MyAction();
action.setServlet( actionServlet );
// don't need ActionForm for this Action class, so use null
ActionForward forward = action.perform( mapping, null, request, response
);
....
}
It works for me, but I was curious if there were better methods others were
using?
Secondly,
I don't know if cactus already does this, but to me the following would be
very useful to keep from having to call config.initParameter() for each of
the struts ActionServlet init parameters ( in the above example, I only set
one, since that's all I needed for the test, but there are many for the
ActionServlet ).
It would be nice if cactus parsed the web.xml file, and provided a way to
associate a servlet with a <servlet> tag in the web.xml file (based on the
<servlet-name></servlet-name> tag) for the purpose of setting up the config
to automatically provide the init parameters specified in the web.xml file.
I would think doing this in the config.setServletName method would be
natural enough
MyServlet servlet = new MyServlet();
config.setServletName( "myserv" ); // this would cause cactus to create the
init parameters for that <servlet-name>
servlet.init( config );
This would be very beneficial, as I would not have to hardcode my
initParameters in my test classes, or create a utility class to parse the
web.xml file myself. I could then change my web.xml file and see the
changes immediately in my test cases without having to recompile them.
Does such a thing seem feasible and useful?
Perry Tew
<snip>
> > >
> > > - help for server side testing of the struts framework, e.g. for
> testing
> > > Actions, ActionMappings etc. How are they testing struts btw. ?
> >
> > Yes, that's a good idea. I have thought about it already and I have 2
> ideas
> > :
> > - provide some mock implementations objects to help unit test struts. We
> > would put these mock objects in a package like
> > org.apache.commons.cactus.extension.struts or something alike and users
> > would be able to use them in their testXXX() methods,
> > or
> > - provide some factory helper classes that return *real* instances of
> struts
> > objects (like ActionMapping, ...). In the current version of Cactus, if
> you
> > want to unit test, say an Action that you have written, you would need
> to
> > manually instanciate an ActionMapping, ActionForm, ... So you need to
> write
> > about 10-15 lines of code to create these objects. The goal would be to
> > replace this code by some helper classes that return these live objects.
> It
> > seems Struts is well written and it would be easy to create real
> instances
> > of objects and initialize them the way we want for the test. However, if
> it
> > is not possible then we'll have to revert to option 1, i.e. provide mock
> > objects which is also fine.
> >
</snip>
