>>>>> "James" == James Mitchell <[EMAIL PROTECTED]> writes:
>> From a "how do I" documentation standpoint, anyone is free to open the jsp
James> files from the test suite and see how different configurations of a
James> particular tag work and are tested. I'm just not sure how all this could be
James> done with the current taglib tests. (At least the ones I've done)
James> I have quite a bit more to do on the current tests and I'm certainly open to
James> suggestions. I chose to setup the tests to utilize the framework and
James> container in a more natural way (setting up and forwarding to jsp
James> pages)....instead of trying to duplicate what the container does. Sure,
James> this requires a bit more overhead with page compilation, but, IMHO, I think
James> it's worth the trade off.
There's very little reason to worry about the "overhead" of page compilation in
the automated unit tests. Speed is not necessary here. In addition, tests of
JSP custom tags which avoid the step of compiling JSP pages which use those
tags are not much of a test, in my view.
It's a little late to mention this, but I would have suggested (actually I
think I did once, briefly) that the Struts tag automated tests could be even
more robust. In my own work, I've started to adapt the approach of forwarding
to a small test page, as you are, but I'm also putting code in the "end"
methods which use the HttpUnit WebResponse class to get the DOM for the
response, and use Xalan's XPath API to really verify that the structure and
attributes of the result is exactly what I expected. I did some of this in
some of the Struts-EL tests, although I hadn't started using your simple test
page idea (I was manually creating the tag objects at that time).
--
===================================================================
David M. Karr ; Java/J2EE/XML/Unix/C++
[EMAIL PROTECTED] ; SCJP; SCWCD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
