On 19/01/10 3:43 AM, John Murph wrote:
On Sun, Jan 17, 2010 at 5:47 PM, Adam Murdoch <[email protected]
<mailto:[email protected]>> wrote:
<snip>
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.
Seems reasonable to me, esp. given the native test direction. How
hard will it be to take such responsibility?
Not too hard, I think. Most of the pieces are there already. I'd like to
end up with the AntTest and NativeTest task sharing the same main
structure, where test detection feeds test classes into one or more test
pipelines. In the case of AntTest, there'd be one pipeline and the
pipeline implementation would be determined by the fork mode (whatever
those end up being).
If we can share the implementation for it between testing and the
UI, that would also be helpful.
I think firstly I'll get AntTest and NativeTest sharing launching code,
and then look at merging in the UI stuff.
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?
I don't see a strong requirement for supporting non-forked tests. As
long as we support a "fork-once" rule and a "fork-every-test" rule, I
think we are good. However, if we are going to support only forked
tests then unifying the ClassLoader hierarchy isn't very relevant.
Does Ant use the application ClassLoader to load the tests?
For forked tests, yes. For non-forked tests, no.
How does it isolate it's own dependencies from the tests like we
want to?
Non-forked mode, I would guess.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
