On 19/05/2012, at 8:41 PM, Szczepan Faber wrote: > The solution should also allow easy debugging.
It should. I'd say the test fixture would probably have a couple of execution modes: * Run the build in-process (but in an isolated ClassLoader). That is, a more convenient but less accurate 'dev mode', similar in intent to our embedded GradleExecuter. * Run the build in the daemon. That is, a less convenient but more accurate 'production mode', similar in intent to our forking GradleExecuter implementations. You'd use the in-process mode if you wanted easy debugging. The execution mode would be combined with several other capabilities, such as whether the client's classes are made visible in the build, and allowing the client to inject code to execute in the build. We may or may not expose these capabilities outside the test fixture. I'm a bit reluctant to do so, but there might be some good use cases for making them available via the tooling API. Either way, I'd start by not exposing them. > > > I was pretty enthusiastic after adding build parameters support to the > > tooling api. However, lack of good strategy to use current classpath > > (classes under test, etc.) does not make tooling api an easy fit for integ > > testing at the moment. Yet, I know for sure some users use it for testing > > quite successfully at the moment. > > Who and how? > > http://ameba.apphance.com/introduction/hello-android > > It's a testing framework for mobile apps, implemented as Gradle plugins. As > far as I know ameba's integ test coverage is dirvautomation is > > Cheers! > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > > -- > Szczepan Faber > Principal engineer@gradleware > Lead@mockito -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
