On Sun, Jan 17, 2010 at 5:47 PM, Adam Murdoch <[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? If we can share the implementation for it between testing and the UI, that would also be helpful. > > 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? How does it isolate it's own dependencies from the tests like we want to? Seems like this would be a solved problem, if we can find/understand the solution. :) -- John Murph Automated Logic Research Team
