In my mind you have a few other options here. You can unit test the tag and
tag extra info classes as Java classes (i.e. just using JUnit), using
simple mock objects for the page context, etc. This way you can pretty
exhaustively test anything you want about the tag. However, you won't be
testing the tag directly from a use perspective, i.e. that <mytaglib:mytag
attribute="whatever" etc . . ./> produces the expected result. For this
"integration" testing you'd need to write JSPs (or generate them on the fly
within your tests), but you don't necessarily need a servlet container. You
can compile the JSP into a java class using your container's jspc, and then
call the resulting servlet's service method with your own simple mock
objects to obtain the response. Here you can use either direct string
comparison or a DOM approach a la HttpUnit.

So, you have other options, and ones that don't involve running your tests
inside a servlet container, but it will take a little work (IMHO well worth
it, however).

Moses



                                                                                       
                                           
                      "Karr, David"                                                    
                                           
                      <david.karr@attws        To:       "'Struts Developers List'" 
<[EMAIL PROTECTED]>               
                      .com>                    cc:                                     
                                           
                                               Subject:  RE: Unit testing taglibs?     
                                           
                      09/25/2002 11:12                                                 
                                           
                      AM                                                               
                                           
                      Please respond to                                                
                                           
                      "Struts                                                          
                                           
                      Developers List"                                                 
                                           
                                                                                       
                                           
                                                                                       
                                           




> -----Original Message-----
> From: Davor Cengija [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, September 25, 2002 12:34 AM
> To: Struts Developers List
> Subject: Unit testing taglibs?
>
> How to unit-test taglibs, possibly without servlet container?
>
> I'm writing wml-related taglib for struts and my code is craving for
> some unit-tests. I found tagunit but it requires servlet
> container, it's
> executed in a jsp page etc. I'd like to have automated unit testing on
> each build.
>
> How does Cactus fit in? I recently discovered it but haven't
> downloaded
> it yet.

If you look in the current unit tests for Struts, you'll find very minimal
usage of Cactus.  You might get a feeling for how this can work for you.
Note that this doesn't really test your TLD file, or how the page might
interact with the JSP compiler, but it does test the actual tag code and
what it does.

When I actually finish committing the Struts-EL code (hopefully in the next
couple of days), you can inspect the unit tests in there, which are based
on
what is in Struts, but which are much more extensive (although I still have
more to write).  These use Cactus, but they also use HttpUnit, Xalan, and
JTidy (and AspectJ, under the covers, by JTidy).  Some of these tag tests
were a little nasty to write, especially for the tags that need the Struts
configuration set up, and which use somewhat complex algorithms to generate
their output.

You'll have to inspect the Struts build process to see how Cactus is really
set up.  Since I just copied that stuff, I didn't have to figure it out :)
.

--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]
>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]
>







--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to