On 30 Jun 2014, at 1:46 am, Daniel Lacasse <daniel.lacass...@gmail.com> wrote:
> Should we have RunTestExecutable implement ExecSpec? > > Following the next story at: > https://github.com/gradle/gradle/blob/master/design-docs/testing-for-native-runtime.md, > I had some thinking about the design. > > We would probably want to sync up later with Test from Java with the > implementation of the interface such as PatternFilterable, VerificationTask > and Reporting<T>. Then I looked at what we currently support with > RunTestExecutable and what is supported in ExecSpec. From my point of view we > could clearly just implement ExecSpec as it provide lots of useful feature > for controlling the test execution. It does provide a method for setting the > executable but Test and RunTestExecutable also provide this capability. The > only thing that would probably be out of place with ExecSpec is > setCommandLine. Then again, we need a method for setting the executable and > another one for setting the arguments. In the end, if someone wants to change > the complet command line, we are not buying anything in extracting an > interface without the setCommandLine. This seems reasonable to me. > > If there is agreement with the last analysis, the fastest logical way of > implementing all this would be to have RunTestExecutable extends from the > Exec task and override the appropriate method. The down side I see with this > implementation is when someone wants to execute something like this > "tasks.withType(Exec)" they would end up receiving RunTestExecutable task > which wouldn't be the desired effect. > > What would be the desired next step in this story? I think there are two options: 1. Change RunTestExecutable to implement ExecSpec. It would delegate to some private ExecAction instance. 2. Extract some superclass out of Exec that both Exec and RunTestExecutable can share. -- Adam Murdoch Gradle Co-founder http://www.gradle.org CTO Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
