Hi,
I'm running into some annoying problems with the AntTest task, which I'd
like to get rid of.
The root problem is caused by the fact that, when the test process is
forked, the classes under test, plus our TestListener implementation,
plus the Ant infrastructure, are all shoved together into the
application classpath.
This has a few unpleasant implications:
1. Any libraries which our TestListener impl uses conflict with the
libraries used by the classes under test. For example, I can't use slf4j
in the TestListener impl, because if the classes under test use it too,
you get (at the very least) the annoying 'multiple bindings' message
from slf4j.
Given that the remote listener stuff is intended to grow into a central
part of our multi-process (and multi-machine) solution, it's going to
need to be able to use various logging and networking libraries (and
their dependencies) to do its work, without interfering with the classes
under test.
2. When the classes under test happen to be the TestListener impl
itself, we get conflicts. This pretty much means we can't change the
impl at all, now that it's being used. This is a bad situation.
An obvious solution to this problem is to switch to the native testing
task. However, I think this is more a Gradle 0.10 time-frame option, as
I don't think it will be ready for the switch in time for the 0.9 release.
Another option is to switch the TestListener stuff off for 0.9, and
switch it back on in 0.10. I think this would be a real shame.
There is, however, a potential middle ground here, which takes us a step
towards native test integration. We could take responsibility for
forking the process, and delegate to an isolated Ant JUnitTask in the
child process, rather than in the parent process. This would give us the
control we need to properly isolate our stuff from the classes under test.
The process launching stuff is more or less already implemented for the
native testing integration, so we could migrate it across, so that the
Ant and native test tasks share this infrastructure. There's also a lot
in common with the process launching stuff in the UI, which we could
potentially merge together.
One implication of this change would be that the classes under test are
no longer loaded by the application ClassLoader. This is something that
tests can accidentally rely on. Instead, they will be loaded by an
isolated ClassLoader. This is a potentially breaking change. However, it
does have the benefit that the ClassLoader hierarchy visible to the
classes under test would be exactly the same for forked and non-forked
tests, which is not the case at the moment. I think this is a good thing
and worth the breakage.
Having said that, one question is whether we want to support non-forked
tests at all. Anyone have any reason for not forking their tests?
My preference for Gradle 0.9 is to get rid of non-forked mode, and take
over responsibility for launching the test process.
Thoughts?
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
