Hi Larry, > -----Original Message----- > From: Larry Tambascio [mailto:[EMAIL PROTECTED]] > Sent: 27 August 2002 15:46 > To: [EMAIL PROTECTED] > Subject: problem using include > > Greetings fellow Cacti (sounds better than cactus'ers), > > I'm not sure if I'm misunderstanding something. I've > gotten a couple of simple ServletTestCases up and going, > so I'm pretty confident about the setup. Moving on to > more substantial tests, I'm running into a problem. My > company has inherited (putting it nicely :-)) a > struts-like framework.
You have several options available to you for testing struts
applications. One is to use the strutstestcase project. See the resource
section on the cactus web site.
The other is to implement it yourself as I tried to describe it in the
attached email (not sure it works though but it may give you some idea).
> I've tried instantiating the
> controller servlet in my test case, but run into problems.
> To circumvent that, I've tried passing on the request and
> response objects to the "actual" instance of the
> controller servlet that starts with Tomcat using the
> include method, as follows.
>
>
> config.getServletContext().getRequestDispatcher
> (request.getRequestURI()).include(request, response);
>
> Pretty ugly, I know. I'm going to clean it up once I get
> it working. :-) In my setUp method, I print out the
> request.getRequestURI, and it shows me the value I expect,
> which I initialized in my beginXxx method. The controller
> servlet barfs, however, because it knows nothing about
> "/ServletRedirector" in the application configuration
> file, and it shouldn't. Based upon my reading of the
> documentation, I thought that the URL I setup in my
> beginXxx method (using request.setURL()) would be passed
> on to any included or forwarded request. Am I incorrect
> in understanding how the include works??
>
Ok. setURL() is simply a way to simulate a URL you would normally get
when calling your application in production. All the http servlet
request calls are wrapped by cactus to use the values defined in
setURL(). However, when you call include() or forward(), Cactus needs to
pass the original request object (not the wrapped one) as this is a
requirements of all Servlet 2.2 engines. It is true that Servlet 2.3+
engines should allow any wrapped request (as is mandated by the filter
spec). This is currently not implemented in Cactus.
That said, I'm not sure what you're trying to do. If you want to call
the struts controller, you simply need to write:
public void testXXX()
{
ActionServlet servlet = new ActionServlet();
Servlet.init(config);
servlet.process(request, response);
}
or do a forward() to the struts redirector (whatever you've mapped it
to).
My question now is : with the above code, what are you testing ? You
need to put something in testXXX() or you are simply performing a
functional test as you could do with HttpUnit. But as you said, that was
certainly only a starting point ...
Cheers,
-Vincent
> Cactus v13-1.4 Tomcat v4.0.1 jdk 1.3.1_04.
>
> Thanks,
> -Larry
>
> --
> To unsubscribe, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
--- Begin Message --- Title: RE: Jsp Test Example?Hi Kevin,
> -----Original Message-----
> From: Wang, Kevin [mailto:[EMAIL PROTECTED]]
> Sent: 22 August 2002 16:52
> To: 'Cactus Users List'
> Subject: RE: Jsp Test Example?
>
> Hi Kaarle and Vincent,
>
> Thanks for the insights. The rationale for unit (vs functional) test jsps
> for us is that jsps and servlets are developed in parallel by different
> developers. I am reponsible for the jsps, including creating templates
> (using Struts template taglibs) and binding data. It would be nice if I
> could unit test jsps before the functional test, which require a fully
> functional servlet component.
>
> After reading the "JspTestCase Principles" carefully. I think there is a
> easy way to "unit" test jsps under Cactus.Ah ok. I understand better what you want to do now. I think you can do it with Cactus.
If I understand correctly, you'd like to be able to test your JSPs with test data coming from the Struts Actions. In other words, you would like to replace the execution of a struts action by some fake data.
Here is how I would do it :
- Create a test class that extends ServletTestCase
- in the beginXXX() method, set up all the needed GET parameters (like the action.do stuff for Struts, etc)
- in the testXXX() method :
private class TestAction extends Action
{
public ActionForward perform(ActionMapping mapping,
ActionForm form,
HttpServletRequest request,
HttpServletResponse response)
{
// store test info in request
// return page to go to
}
}public void testXXX()
{
ActionServlet controller = new ActionServlet();
controller.init(this.config);
ActionConfig actionConfig = new ActionConfig();
actionConfig.setType(TestAction.class.getName());
actionConfig.setPath("path/to/action");
ApplicationConfig appConfig = (ApplicationConfig)
this.request.getAttribute(Action.APPLICATION_KEY);// register our Action
appConfig.addActionConfig(actionConfig);// run struts
controller.process(this.request, this.response);// perform any assert here if need be
}public void endXXX(HttpUnit WebResponse)
{
// perform HTML validation
}There you go. Refactor all this cleanly. Maybe create a StrutsTestCase class that extends ServletTestCase and provide 2 methods : addAction(path, Action) and process(request, response).
Then your code can be :
public class MyTestCase extends StrutsTestCase
{
public void testXXX()
{
addAction("path/to/action", new Action() {
public ActionForward perform(ActionMapping mapping, ActionForm form,
HttpServletRequest request, HttpServletResponse response)
{
// store test info in request
// return page to go to
}
);process(request, response);
}public void endXXX(WebResponse)
{
[...]
}
}... and off you go ! :-)
Ok, there is a bit more to figure out but that should give you a good idea.
You can also have a look at the StrutsTestCase project which can work on top of Cactus. I think they may have followed this approach but I haven't looked at that project (it is on SourceForge).
Hope it helps.
-VincentNote: If you succeed in making this work, I would be very interested if you could submit your result so that I can add this to the FAQ or even add helper classes to Cactus CVS (like the StrutsTestCase class). Thanks.
>
--- End Message ---
> Thanks.
> Kevin
>
> -----Original Message-----
> From: Vincent Massol [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, August 22, 2002 3:36 AM
> To: 'Cactus Users List'
> Subject: RE: Jsp Test Example?
>
>
> Hi Kevin,
>
> Kaarle is completely right, you would test that in the following ways :
>
> - write a pure junit test for your java bean (as they have no
> dependencies on the environment). You can also use Cactus if you wish to
> have only one framework to set up.
> - write cactus unit tests for taglibs (using JspTestCase)
> - write cactus unit tests for your servlet controller and other classes
> manipulating the servlet api (using ServletTestCase)
> - write cactus functional tests for the returned HTML (using the
> HttpUnit integration - see web site for details)
>
> Thus Cactus offers you a full solution for unit testing your web
> application ! :-)
>
> Hey I will put this as a FAQ ...
>
> Thanks
> -Vincent
>
> > -----Original Message-----
> > From: Wang, Kevin [mailto:[EMAIL PROTECTED]]
> > Sent: 21 August 2002 21:00
> > To: 'Cactus Users List'
> > Subject: Jsp Test Example?
> >
> > Does anyone have an example for testing Jsps? I looked over the
> examples
> > but
> > could not find any.
> >
> > The jsp is the view in our model. A servlet would populate the "bean"
> > object
> > and put in request and forward it to the jsp. The jsp would have the
> > following:
> >
> > <jsp:useBean id="bean" class="Bean" scope="request" />
> > <%@ include file="../another.jsp" %>
> > <%= bean.getName() %>
> > ...
> >
> > How would one test the jsp using Cactus in this case?
> >
> > Thanks.
> > Kevin
> >
> > --
> > To unsubscribe, e-mail: <mailto:cactus-user-
> > [EMAIL PROTECTED]>
> > For additional commands, e-mail: <mailto:cactus-user-
> > [EMAIL PROTECTED]>
>
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:cactus-user-
> [EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
