myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <craig...@apache.org>
Subject Re: tomahawk/src/test has dependencies on MyFaces Impl
Date Mon, 20 Mar 2006 06:18:01 GMT
(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 <dennis@dbyrne.net> 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

Mime
View raw message