While we are on a similar subject, I will relate another test
frustration I had when moving to Maven and have not found a gradle
solution I like yet (though I've since dropped maven). I think the
proposed integration test idea may be related.
One of my modules is a utility library that amongst other things has a
bunch of reflection utilities. Another module we have implemented some
junit extensions to make testing a little easier... it leverages the
utility library.
Eating our own dog food, some of the unit tests for the utility package
rely on the junit extensions.
In ant, this was easy. Everything was compiled then everything was
tested. Packaging of the separate jars was just a few lines of ANT
script and lacked any package dependencies, etc. ala maven.
Even though "util" compile has no dependencies on "junit-ext", Maven and
Gradle see this as a circular dependency (and from a certain
perspective, rightly so). Because "test" has to run before packaging,
the overall dependencies are circular: util package depends on junit-ext
package which depends on util package. When really it is util test
depends on junit-ext package... if there were a post-package integration
test phase then I might have a clean way of working around this issue.
All of the dogmatic solutions were worse than the disease and I've
ultimately removed the dependencies (in some cases by just not running
otherwise perfectly valid tests).
-Paul
Russel Winder wrote:
Steve,
Your email must have arrived just as I was sending my last one . . . !
On Mon, 2009-08-03 at 15:09 -0400, Steve Appling wrote:
[ . . . ]
Traditionally in Maven and in Gradle, tests were run against the classes dir
because passing the test was a precondition for building the jar (jar depends on
test). This happens to have just changed in Gradle (over the weekend). Jar no
longer depends on test and there is a set of new tasks starting with "build"
that will both test and compile.
I think there is a strong role for this pre-packaging testing. I have
no problem with it. The problem I have is that Maven, Eclipse, IntelliJ
IDEA, and I fear Gradle, only support this mode of testing. Integration
and system testing are not actually supported at all. Maven has an
integration-test phase but the classpath used is basically just the same
as test which is fundamentally useless. As for Gradle, I suspect I need
to RTFM :-)
Test, however, is still running out of the classes dir and not off of the jar.
I'm not convinced that this is wrong, but we should allow you the flexibility to
change it. The JavaPlugin adds the classes dir to the testCompile configuration
(see JavaPlugin.java line 245 in the trunk). The DependencyHandler doesn't have
a good way of removing dependencies only adding them. Perhaps you could replace
the testCompile configuration with a copy filtered using one of the filtering
forms of Configuration.copy. There needs to be a better way of customizing
things like this.
Actually I am not sure I want to change the test phase, what I want to
do is have a proper integration/system test phase (which Maven doesn't
have despite the integration-test phase). If I look at what I have as
unit tests in Gant, it is clear that some are unit tests in the classic
sense, and some are integration tests. The standard model has forced me
to lump them all together and it is this that is causing me the
problems.
I need to separate out the real unit tests (which can happily be
compiled in the classic "against the directory" mode) from what are
really integration and system test, for which Eclipse, IntelliJ IDEA,
Maven, and I suspect Gradle, have no real support.
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
