On 17/05/2012, at 11:54 PM, Luke Daley wrote: > This is not really practical right now, unless I'm missing something. > > We need a convenient way to inject the classes under test. I spent a little > time looking at this and couldn't come up with a satisfactory strategy.
There's a lot of overlap here between what we want to do for testing, and what we want to do for configuration injection. It's more or less the same problem: I have some code + state visible to me that I want to execute in a different context (ClassLoader and/or process), but I don't want to have to set any of this stuff up. I also want to be able to refer to some of the state from my original context, and sometimes get a result back. In the case of integration testing, we want something like: * A way to run a Gradle build and make the test's classpath visible to the build script. More or less what our in-process GradleExecuter does. * A way to run a Gradle build isolated from the test's classpath, so that I can int test the real packaging. More or less what our forking GradleExecuter does. * A way to run the entire test in the Gradle 'container', effectively as if the test were a build script. This is the same problem that WorkerProcess solves, along with its early in-process equivalent inside InProcessCompilerDaemonFactory. So, we have the pieces for moving code from one isolated context to another. We'd need to shuffle some of this around so that there's a consistent interface regardless of whether the work is travelling to another process or not, add some convenience that understands closures, and wrap it in some public integration test fixtures. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
