Add Args to RunTestExecutable for Native Test

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Add Args to RunTestExecutable for Native Test

Daniel Lacasse
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.

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?
Reply | Threaded
Open this post in threaded view
|

Re: Add Args to RunTestExecutable for Native Test

Adam Murdoch

On 30 Jun 2014, at 1:46 am, Daniel Lacasse <[hidden email]> 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



Reply | Threaded
Open this post in threaded view
|

Re: Add Args to RunTestExecutable for Native Test

Daniel Lacasse
I think option #2 is the best in term of code duplication. I will then extract the required implementation into an abstract class - org.gradle.api.tasks.AbstractExecTask which follow the same idea of the current AbstractCopyTask.

I will move forward with this.


On Sun, Jun 29, 2014 at 7:41 PM, Adam Murdoch <[hidden email]> wrote:

On 30 Jun 2014, at 1:46 am, Daniel Lacasse <[hidden email]> 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






--
Daniel