On 13/09/2011, at 7:02 PM, Luke Daley wrote: > > 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.
It doesn't need a packaged distribution. The daemon can be launched from the classpath. So such a test would not need a packaged distribution in 'embedded' mode. It would need a distribution in 'forking' mode, because, by definition, when in that mode, the test is covering that things work against a distribution. > > 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. Sure it is. If you read the method names, and looks at what they cover, this is a test that describes how the daemon should behave regardless of how one interacts with Gradle. You just need to replace calls to DaemonRegistry and DaemonConnector with calls to methods on an interface that describes the operations at a high level, and you've got your high level functional description of the behaviour we want. Keep in mind that there are daemon management capabilities we want to add to the command-line client, and possibly the tooling API, such as being able to query the status of the daemons. This test is simply describing the things a human would do to interact with the daemon: run a build, query what the daemons are doing, maybe start another build, or run 'gradle --stop' or whatever. > 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. We want our integration tests to cover the ways that a human interacts with Gradle. That is, by running 'gradle' on the command-line, or invoking the tooling API. And later, we want some coverage for a human using the GUI. We might even end up reusing these tests to drive eclipse or idea directly to interact with Gradle, to test our IDE integration. So, it's not really about covering the daemon modes. It's about covering the public behaviour that a human can use. Currently, we have cross cutting coverage of the daemon, by running all of the integration tests using a fixture that happens to run the build in the daemon. If we decide that we want to make embedded daemon mode a public capability, we would run the same tests using a fixture that runs the build using the embedded daemon. In fact, I think we should probably replace the existing in-process executor with the embedded daemon executor. > > 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. If we have a reusable integration test, then I don't see that DaemonFunctionalTest add any value at all. We just have to pay the cost to keep the test cases in sync. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
