I have been thinking about Tag testing too (hmmm good alliteration
there).
See comments below:
Vincent Massol wrote:
>
> In the current version Cactus does not support unit testing of Taglet that
> extend TagBodySupport and that make use of bodyContent (it does support
> however, unit testing of Taglet that extend TagSupport).
>
<snip>
>
>
> Would that work ?
> The only issue I can see so far, is if the body content contains another
> nested tag ... Hum ...We are doing unit testing here, meaning that we are
> not testing a nested tag. So we simply have to put in the bodyContent the
> expected result from a nested tag ... What do you think ?
>
I think we need to do more "wrapping", i.e. to provide a wrap of the
pagecontext and the JSpWriter. Otherwise a tag can call methods like
getRequest(), getResponse(), etc and bypass the wrapped versions, which
doesn't seem right to me. If we're going to wrap the API, then let's
wrap the API, the whole lot of it...
Some methods that would cause "escape" from the testing classes in
PageContext:
popBody(),
pushBody(),
getRequest(), getResponse(), getServletConfig(), getServletContext(),
getSession()
If you wrap the JspWriter returned by the getOut call on PageContext,
then it would allow you to have server side control over output to the
page, and you could
- record sequences of calls to allow assertion in testXXX methods,
- allow normal "passthru" of calls and test JSP output in endXXX methods
on the client, or
- do a mixture of both.
so you could wrap and record usage of methods like print(long l), or
print(Object o)- preserving type. Once you hit the client and the endXXX
methods then you've lost type information- everything is now a string.!
Not sure if this strays into the "mock" idea or not, but I don't see why
a "CactusJspWriter" class shouldn't keep what calls are made to it in a
"test friendly" manner.
This would be just as useful for tags that extend Tag, not just for
BodyTag.
Nesting:
---------
You would need to include in a FAQ how to set up a test for nested tags,
it's not enough to just construct a tag instance and test it - it the
tag expects to be nested, then you must mimic the generated JSP code in
your test case and call setParent( some tag) if a tag expects to be
nested.
Ultimately, I don't know how far you can get in testing the behaviour of
a tag library without actually writing out JSP and testing what the JSP
container produces somehow. Otherwise how do you test the behaviour of a
tag with nested tags, or of the nested tag itself, without mimicing the
generated JSP code. I think testing of JSP is going to prove just too
hard in some cases - the fact that you can write whatever you want in a
JSP page following two sets of syntax, JSP, and Java, makes it bloody
hard - it's like trying to test two languages at the same time :(
Jari
--
Jari Worsley
Senior Programmer
Hyperlink Interactive Ltd
