On 3/17/06, Dennis Byrne <
[EMAIL PROTECTED]> wrote:
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 :-).
+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.
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.)
>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
