On 25/08/2011, at 11:58 PM, Luke Daley wrote: > Hi, > > I am working on some bits around our integration testing fixtures and > thinking about what a publicly usable version of this might be like. > > Do you think we would want to allow people to execute Gradle in different > manners like we do? If I'm developing a plugin and want to integration test, > am I really going to want to test with the daemon, and embedded etc? > > Initially, I was inclined to think that we should *only* support testing > using a forking mode (daemon or not) but I guess users will want to have the > choice of making the same tradeoff that we do where we run embedded for speed > during development and trade off accuracy.
I can think of a couple of problems with forking mode, from a developer point of view: * You can't (easily) debug the code under test in the IDE. * You can't (easily) inspect the state of the model in the test, similar to what our plugin unit tests do. A simple solution to the first problem is to have some way to run the test build in-process. We can make our current in-process executor much more accurate by having it use the tooling API in in-process mode, which better isolates things from each other. Plus you don't necessarily need all of the Gradle runtime on your classpath to use it. If we were to do this, I'd make in-process the default mode for test build execution (in fact, I think I'd always make it the default, regardless of accuracy, because it's so much more usable). Not sure what to do about the second option. For that to work, you'd need at least all of the Gradle API on the test classpath. Might be interesting to offer an in-classloader execution mode for the tooling API. This way, a client of the tooling API, not just tests, can tightly couple itself to a particular Gradle version, but in making that trade-off can use all of the model. I'd really like the int test fixture API to be synched up with the tooling API, so that the testing stuff adds a testing specific dsl to the 'run a build/get the model' dsl that the tooling API provides. This is because, the way I see it, whatever capability a test needs, there's probably some production code that needs exactly the same capability. In other words, tests are just another client of the tooling API. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
