struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: Standalone Tiles: Status and Call for Help
Date Wed, 22 Mar 2006 17:45:53 GMT
On 3/22/06, Greg Reddin <> wrote:
> On Mar 21, 2006, at 6:04 PM, Craig McClanahan wrote:
> > For a library claiming to be "standalone", I would be a little
> > cautious
> > about depending on either set of mock object APIs.
> Certainly, no such dependencies should be in the core software, but
> dependencies in the test cases are acceptable, right?  I suppose we
> could modify the existing tests to use mock implementations of the
> context once we get that figured out.  Even so, context
> implementations that work with Servlet API, Faces, Portlet, etc. will
> need tests.  Does all that stuff need to be optional?

I was rambling a bit in that paragraph (and I seem to have changed my mind
about half way through :-) ... let me try to be a little clearer.

The Shale test framework classes include mock implementations of essentially
all APIs in the servlet spec (as well as JSF, but that's not really relevant
here).  As such, it can be used as a source of things like
MockServletContext, MockHttpServletRequest, and so on.  It *should* be
possible to use this jar file for Tiles tests, even if you don't have
jsf-api.jar in the classpath, as long as you don't try to use things like
MockFacesContext.  The end result is we should be able to construct JUnit
based tests for nearly everything in standalone Tiles, without the
complexity of Cactus tests.  (For in container testing, I prefer to set up a
"real" app and then exercise it with things like HtmlUnit.)

The only place it might fall down a little for you is in testing custom tags
... there's no current implementatino of things like MockPageContext.
That's a solvable problem, though, by just writing a few more classes.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message