We cover two types of tests for JSPs,
* Isolate the JSP from the back end by mocking the input JavaBeans it uses, and then verifying that the returned page contains the expected data.
* Direct tests on JSP custom tags used in the JSP with either Cactus or Mock Objects.
All my new development is test-first now. The idea being, if your going to write the test anyway, you might as well write the test first and get the most use out of it. Typically, I have a core Unit Test for the back end code and then Struts TestCases for the Actions.
It's getting so that I have to remind myself to click through the application now and again, just to be absolutely sure its passing the "acceptance tests".
-Ted.
And, Craig, Deryl's Struts TestCase may be way-cool and fashionable, but you're still like a brother to me =:0)
James Turner wrote:
The other thing we all need to get better about is committing test cases to the (currently pretty woeful) unit tests in Struts, so that we can protect ourselves against regressions later. But I'm willing to forgo that for now, as long as we (as a group) make it a high priority post-1.1 goal.
I have major problems (both for Struts and with my client's projects) about regression testing, specifically with JSP. This is really causing problems for us in Struts, because many of the things that are coming up are taglib-related and nearly impossible to accurately unit-test. I'd love to see a good solution proposed for this, I've tried Cactus and it's a good half-way step, but still doesn't really test the code on the JSP page.
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
