On 2/16/06, Bill Dudney <[EMAIL PROTECTED]> wrote:
That's been my experience as well.
For Struts, the most important place where Cactus makes sense is testing all of the custom tag implementations, because it is not particularly easy to mock all of the dynamic behavior of a JSP page. For JSF components, this is less of a concern -- a well behaved component tag should be doing very little other than copying in the appropriate attribute values. The most important things to test are what the Renderers produce, and the ability of a component class to save and restore its state. Both of those are quite amenable to unit testing with mocks.
For components, I would also suggest some client-server tests using something like Canoo or HtmlUnit. This is especially helpful in evaluating how compojnents interact with each other at runtime, especially if there is _javascript_ execution going on. This technique is also useful for testing applications themselves, as well as the components.
Craig
Hi All,
If we have good mock support there is no real reason to continue with
any particular cactus test. It is much easier and faster to run tests
in JUnit if you have a good set of mocks. So lets go down that way.
That's been my experience as well.
For Struts, the most important place where Cactus makes sense is testing all of the custom tag implementations, because it is not particularly easy to mock all of the dynamic behavior of a JSP page. For JSF components, this is less of a concern -- a well behaved component tag should be doing very little other than copying in the appropriate attribute values. The most important things to test are what the Renderers produce, and the ability of a component class to save and restore its state. Both of those are quite amenable to unit testing with mocks.
For components, I would also suggest some client-server tests using something like Canoo or HtmlUnit. This is especially helpful in evaluating how compojnents interact with each other at runtime, especially if there is _javascript_ execution going on. This technique is also useful for testing applications themselves, as well as the components.
Craig
From what I remember all the cactus tests that I did were more or
less tests to help find a JIRA bug or to assure that the bug would
not come back. If we can do the same with mocks then that is the way
to go IMO.
Thanks Dennis for porting the tests over!
TTFN,
-bd-
On Feb 15, 2006, at 10:20 PM, Dennis Byrne wrote:
>> Now that Dennis is
>> considering leading the charge on adopting the Shale Mock Test stuff
>> maybe we could consider porting the cactus tests to use the mock
>> stuff.
>
> I'm not considering it, I'm going to do it - once I am no longer
> doing overtime for my day job.
>
>> My preference is for mock over the container testing since its much
>> simpler.
>
> The cactus tests I saw (in MyFaces) were for HtmlSelectOneMenu . I
> recall the rendered output was being tested. I thought it was
> pretty cool, but you can do this outside of container. These links
> will wrap, but here is a test for HtmlSelectOneMenu using shale mocks.
>
> http://cvs.sourceforge.net/viewcvs.py/jsf-comp/test/src/java/org/
> apache/myfaces/test/AbstractUIComponentTestCase.java?rev=1.2&view=auto
>
> http://cvs.sourceforge.net/viewcvs.py/jsf-comp/test/src/java/org/
> apache/myfaces/component/html/ext/
> AbstractHtmlSelectOneMenuTestCase.java?rev=1.2&view=auto
>
> You can just run it in JUnit, and get a String w/ the HTML.
> However if we have someone willing to get the Cactus tests up in
> Continuum, I'm sure we don't have to treat this as "Cactus or No-
> Cactus" .
>
> Dennis Byrne
>
>
>
