You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Colin Sampaleanu <co...@exis.com> on 2003/09/24 21:23:17 UTC
Testing abstract page classes
I'm wondering how people are generally testing page (and component)
implementation classes, in a standalone environment (ie not running in a
Servlet engine in a Tapestry app), given that a lot of the time the
classes will be abstract due to the use of <property-specification>
elements?
The approach that immediately comes to mind is to mock everything the
page works with, and then test against a subclass which actually
implements the missing functions, but I wonder if there are other
approaches?
Regards,
Colin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Testing abstract page classes
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
My plans for 3.1 are to add a real testing framework to Tapestry that would simplify this; haven't
even fully brainstormed what it would look like, but I expect it would evolve up from the internal
testing framework that Tapestry uses: mock implementation of the Servlet API grafted to a kind of
XML script.
--
Howard M. Lewis Ship
Creator, Tapestry: Java Web Components
http://jakarta.apache.org/tapestry
http://jakarta.apache.org/commons/sandbox/hivemind/
http://javatapestry.blogspot.com
> -----Original Message-----
> From: Colin Sampaleanu [mailto:colinml1@exis.com]
> Sent: Wednesday, September 24, 2003 3:23 PM
> To: Tapestry users
> Subject: Testing abstract page classes
>
>
> I'm wondering how people are generally testing page (and component)
> implementation classes, in a standalone environment (ie not
> running in a
> Servlet engine in a Tapestry app), given that a lot of the time the
> classes will be abstract due to the use of <property-specification>
> elements?
>
> The approach that immediately comes to mind is to mock everything the
> page works with, and then test against a subclass which actually
> implements the missing functions, but I wonder if there are other
> approaches?
>
> Regards,
> Colin
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org