On 11/09/2011, at 11:18 PM, Adam Murdoch wrote: > > On 11/09/2011, at 6:09 PM, [email protected] wrote: > >> Branch: refs/heads/master >> Home: https://github.com/gradle/gradle >> >> Commit: 05308efa20db9712f2def074e9e2cb3577dbb86b >> >> https://github.com/gradle/gradle/commit/05308efa20db9712f2def074e9e2cb3577dbb86b >> Author: Szczepan Faber <[email protected]> >> Date: 2011-09-11 (Sun, 11 Sep 2011) >> >> Changed paths: >> M >> subprojects/integ-test/src/integTest/groovy/org/gradle/integtests/daemon/DaemonFunctionalTest.groovy > > I think this should become a real integration test. If you look at the method > names, they reflect features we want Gradle to have regardless of which > interface you use: daemons expire, stops all daemon, starts a new daemon if > daemon is busy, etc. This is stuff we want coverage for, so it would be nice > if we can reuse this test in different contexts.
I'm not 100% sure that this should be an integration test, in the same manner as our existing integration tests. This could be a unit test, except that it needs a packaged distribution so it's convenient to make it an integration test. I don't see how this test makes any sense for the non-daemon executers. It's highly targeted at the mechanics of the daemon and not general enough to describe general gradle functional usage. This should cover both daemon modes though, and that can be solved vi making this abstract with a template method that returns a DaemonRegistry impl to work with for the test. I think we do need a test that works with all executers that simulates things like the user trying to run two builds at once with the same user account etc. but I do think that's a separate test as it's at a higher level. -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
