Re: Example of in use

[James Mitchell <jm...@apache.org>]

----- Original Message -----
From: "Ted Husted" <hu...@apache.org>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Saturday, May 31, 2003 7:48 AM
Subject: Re: Example of <html:select> in use


> James Mitchell wrote:
> > In a way, I was hoping the test cases I wrote recently would sort-of
take care
> > of this.  Although they are not as newbie friendly as a nice deployable
war,
> > they demonstrate the before and after souce view of (more or less) every
> > possible configuration of every tag.
> >
> > They need a bit of refactoring and they are not complete for every tag
(yet),
> > but I think I got a nice start on them and I hope to have the time soon
to
> > finish them.
>
> I wonder if we could set it up so that the taglib test classes can be
> complied into a special taglib-exercise JAR and bundled with the
> exercise application (source and all). We might then be able to pick
> some of the key tests and present the source code, as Steve is doing.
>
> So there would be both the test pages and the JUnit tests in the
> exercise WAR.
>
> The goal here would be to show people how taglibs can be tested, and
> also to show people how we are testing our taglibs [in case they want to
> pitch in =:0)]. We might also add the other tests sometime, so that this
> becomes a complete testing application for Struts.
>
> So, we'd have the MailReader example showing Struts being used to solve
> a specific business problem, Steve's "Struts University" examples
> showing how to implement various use-cases, the exercise application
> with our unit tests, and the Tiles and Validator examples.
>
> At some point the Struts University examples might absorb the Tiles and
> Validator examples, so we could have just the three (MailReader,
> University, and Exercise).
>
> Of course, there might still be others in contrib, for the JSF tags and
> other optional packages.
>
> -Ted.
>

>From a "how do I" documentation standpoint, anyone is free to open the jsp
files from the test suite and see how different configurations of a
particular tag work and are tested.  I'm just not sure how all this could be
done with the current taglib tests. (At least the ones I've done)

I have quite a bit more to do on the current tests and I'm certainly open to
suggestions.  I chose to setup the tests to utilize the framework and
container in a more natural way (setting up and forwarding to jsp
pages)....instead of trying to duplicate what the container does.  Sure,
this requires a bit more overhead with page compilation, but, IMHO, I think
it's worth the trade off.

Comments?

James Mitchell





---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org

Re: Example of in use

["David M. Karr" <dm...@earthlink.net>]

>>>>> "James" == James Mitchell <jm...@apache.org> 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++
dmkarr@earthlink.net   ; SCJP; SCWCD




---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org