On 26/08/2011, at 4:56 AM, Adam Murdoch wrote: > 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).
Makes sense. Does the tooling-api currently support this in process mode? Seems like this would be reliant on the daemon supporting an in process mode (which is next on my to-do list). We're also going to need to support using the tooling-api with a custom classpath so the user's classes are exposed to the gradle version the tooling api is driving. Or, we force it all to be packaged up into a distribution of course but that doesn't seem good. > 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 can see that being very useful. It seems logical that people would want to poke around the model after running some tasks. > 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. Makes sense. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
