I've read a message in the Cactus archives from Deryl which verifies that the getText method of the WebResponse object will return an empty string since the CactusStrutsTestCase quits once it gets the ActionForward back from the Action class.
Is there anyway to get the actual web page response, so that I can also parse some of the html being returned?
The processForward method of the ActionServlet is protected, so it does not appear to be possible to call it from within the actionPerform method of CactusStrutsTestCase.
Thanks,
Cary
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2002-05-03
I too found myself stuck at the same point. I wanted to combine my CactusStruts test with some post-processing using an HTTPUnit test to check the HTML. But since that HTML doesn't get generated (obviously) until *after* the Struts Forward is followed to my JSP page, I would get back empty WebResponse classes.
I don't see an easy way to fix this problem in the code. But one way might be to subclass ActionServlet, make those "process()" methods public, and then somehow tie them into CactusStrutsTestCase, after it does the perform() method.
But, for two reasons, I've decided that the better solution might be to make the HTTPUnit tests *separate* from the Struts test, and not try to force CactusStrutsTests to do something it doesn't want to.
My reasons are as follows. First, the current way CactusStrutsTests run is very "unit" oriented. You never go beyond *one* Forward. If your Actions were at all chained together with Forwards, then it would be very hard to test this if CactusStrutsTests kept following those Forwards until the end. I think you would lose all of the information in-between.
Second, we're really testing two different things here. CactusStrutsTests can tell us that the logical "flow" of the pages is correct. HTTPUnit tests can tell us that our individual JSP/Servlets are feeding us what we think they are.
And even though it means you have to setup a single test *twice*, once for CactusStruts, once for HTTPUnit, it might be worth it, just to keep things properly unit-ized.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've read a message in the Cactus archives from Deryl which verifies that the getText method of the WebResponse object will return an empty string since the CactusStrutsTestCase quits once it gets the ActionForward back from the Action class.
Is there anyway to get the actual web page response, so that I can also parse some of the html being returned?
The processForward method of the ActionServlet is protected, so it does not appear to be possible to call it from within the actionPerform method of CactusStrutsTestCase.
Thanks,
Cary
I too found myself stuck at the same point. I wanted to combine my CactusStruts test with some post-processing using an HTTPUnit test to check the HTML. But since that HTML doesn't get generated (obviously) until *after* the Struts Forward is followed to my JSP page, I would get back empty WebResponse classes.
I don't see an easy way to fix this problem in the code. But one way might be to subclass ActionServlet, make those "process()" methods public, and then somehow tie them into CactusStrutsTestCase, after it does the perform() method.
But, for two reasons, I've decided that the better solution might be to make the HTTPUnit tests *separate* from the Struts test, and not try to force CactusStrutsTests to do something it doesn't want to.
My reasons are as follows. First, the current way CactusStrutsTests run is very "unit" oriented. You never go beyond *one* Forward. If your Actions were at all chained together with Forwards, then it would be very hard to test this if CactusStrutsTests kept following those Forwards until the end. I think you would lose all of the information in-between.
Second, we're really testing two different things here. CactusStrutsTests can tell us that the logical "flow" of the pages is correct. HTTPUnit tests can tell us that our individual JSP/Servlets are feeding us what we think they are.
And even though it means you have to setup a single test *twice*, once for CactusStruts, once for HTTPUnit, it might be worth it, just to keep things properly unit-ized.