Task.execute() deprecation in 5.0

Help/Discuss
1

As from 4.3 (I think) I have been seeing the following warning:

The TaskInternal.execute() method has been deprecated and is scheduled to be removed in Gradle 5.0. There are better ways to re-use task logic, see https://docs.gradle.org/4.3.1/userguide/custom_tasks.html#sec:reusing_task_logic.

I would not use the method in normal plugin implementations as it does not lead to good practice. However, it is quite useful in some unittests as it allows one to invoke the task directly withou having to remember what the method is with the @TaskAction annotation.

Thus my question to Gradle folks are, what would be the recommendation to replace this with in unittests.

2

The recommendation is to not unit-test tasks, but instead

  • unit test the logic independently of any Gradle code by breaking it out of the Task implementation
  • use TestKit to do functional testing of the tasks
3

I just knew you were going to say that @st_oehme :grinning:, and I am in agreement with that.

There are certain cases where calling the task action direct served a purpose, especially when chekcing state changes within the class. Maybe it can possibly just be deferred to be tested in TestKit, but that does add execution overhead time, especially where the interest was purely to inspect a state change in the task class.

I suspect quite a bit of legacy test code might breaks for plugin authors, but it also means that it is probably time to rework their code anyway to deal with later Gradle features.

4

The only (unsupported) way to test a task’s execute() method in isolation was to use ProjectBuilder, which is pretty slow as well. If you want lightweight tests, then it’s best to split out the logic into its own class, so you don’t need all the surrounding Gradle infrastructure.

5

When you say unsupported, can I assume that this only refers to testing task execution with ProjectBuilder?

I use the latter a lot to test basic configuration of tasks and extension i.e. usage in configuration phase and not execution phase.

6

Yes, I clarified the answer above.

7

Just to complain about this again. I just had a number of cases where having the execute in tests would have saved me quite a bit. Now I am havign to write a lot more GradleTestKit code, which effectively adds both development and execution time.

1 Like