myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <>
Subject Re: tomahawk/src/test has dependencies on MyFaces Impl
Date Mon, 20 Mar 2006 08:03:10 GMT
For properly testing against both APIs and IMPLs, we'd need to have the RI be

1) maven2-nized

2) with a compatible license.

Now, license issues have been resolved for most of the licenses we
deal with. Was the CDDL amongst the libraries we may deliver binaries
with? I do believe so...



On 3/20/06, Craig McClanahan <> wrote:
> (Coming back from London after a couple of days out of touch, so this might
> be old news, but ...)
> On 3/17/06, Dennis Byrne <> wrote:
> > >One -- you're actually limiting or biasing the test coverage for this
> > >particular test because you're testing against a particular
> > >implementation rather than a more abstract mock object.
> >
> > Yes, this is an argument that is as old as QA itself ;)
> And it would be exactly the same if the tests were using a MyFaces-specific
> mock object :-).
> The point is that you *cannot* test the behavior of many JSF related objects
> without more than a "pure abstract" implementation of the mock objects.  I'm
> sure that is true in most scenarios that use mock objects for a testing
> strategy, but it is clearly true here.
> Want proof?  You wouldn't believe how many times the Shale test framework
> had to flesh out implementations of abstract methods (that used to just
> throw UnsupportedOperationException) before the framework was actually
> usable in testing MyFaces components :-).
> > >Two -- by requiring impl to be a dependency for the test code, you
> > >allow the possibility of unintentionally using impl classes in the
> > >non-test code.
> >
> > As long as impl is scoped as "test" in the pom.xml for tomahawk, I don't
> see how maven would allow one of us to compile the non-test code.
> +1.  In order to test components correctly, it is vital that the
> compile-time and runtime classpaths for the tests include the API jar file
> and the test framework, but *not* the impl classes.
> HOWEVER ... this condition is merely "necessary but not sufficient".  That
> is because JSF has quite a lot of "implementation" functionality built in to
> the API classes as well, so you could still end up with unintended
> dependencies on the MyFaces API classes.  A robust testing strategy for
> components would execute against both (a) MyFaces API + Test Framework, and
> (b) JSF RI + Test Framework.  Along with, of course, runtime tests against
> both API+IMPL combinations.
> > >Another observation is that end-users cannot download, build, test
> > >Tomahawk without MyFaces impl.   Since Tomahawk is supposed to be
> > >JSF-implementation independent, it's contrary to our stated goal to
> > >require a specific implementation for testing or development.
> >
> > Obviously we want people to use tomahawk w/out myFaces impl.  If you would
> like to make it possible for them to test tomahawk w/out impl than more
> power to you.  I think this is taking it too far and we will never get a pat
> on the back for this.
> Isn't this the basic motivation behind migrating to a "shared" or "commons"
> artifact that both the MyFaces impl and the components can depend on,
> without creating a mutual dependency?  (But that only deals with part of the
> problem, as the previous response paragraph describes.)
> > Dennis Byrne
> >
> >
> >
> Craig


Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German

Professional Support for Apache MyFaces

View raw message