I don’t feel good writing code not tested properly by automatic tests. Many things in a Gradle plugin cannot be unit tested and I have a need to write some integration tests to ensure the my plugin really works. I’ve seen integration tests of the internal Gradle features written with AbstractIntegrationSpec and I would like to be able to use it in my plugin to get at least a part of automation shown by Szczepan at GeeCON 2013.
Why the integration test infrastructure from the internalIntegTesting module couldn’t be packaged as a separate jar to allow for its usage in a test scope of the external plugins?
I did a try and with some hacks I was able to write some real integration tests which can be used to do smoke testing of my plugin with different Gradle version (manual testing before every release of my plugin was very boring).
Nevertheless it would be nice to have it working without manual work (hacks) to be able to run it from a CI server and I collected things that don’t allow to do that to start a discussion and (hopefully) convince you to make that changes (or at least to accept them - with your support I could probably do most of the dirty work).
Two main problems:
Some Gradle artifacts are not being already publishing into Gradleware repository, but gradle-internal-integ-testing and its dependencies like gradle-messaging, gradle-native, gradle-internal-testing, gradle-launcher are missing. It would be required to deploy also those artifacts and/or refactor gradle-internal-integ-testing to have less dependencies (e.g. is gradle-launcher really needed?).
testFixtures which could be used by the external test suites or worse which are used internally by gradle-internal-integ-testing. Currently they are available from the other Gradle modules, but are not packaged which makes them invisible in a development of external test suites. I have no clear idea what would be the best solution here (separate *-testFixtures.jar packages?).
What do you think about that? What do you propose to do next to make it happen?