Fix the @Retry documentation

[Vampire]

No description provided.

[Vampire]

• Fix the @Retry documentation #2174 👈 (View in Graphite)
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 82.06%. Comparing base (6db37a3) to head (989e118).

Additional details and impacted files

@@             Coverage Diff              @@
##             master    #2174      +/-   ##
============================================
- Coverage     82.07%   82.06%   -0.01%     
+ Complexity     4756     4755       -1     
============================================
  Files           465      465              
  Lines         14871    14871              
  Branches       1878     1878              
============================================
- Hits          12205    12204       -1     
  Misses         1978     1978              
- Partials        688      689       +1     

Files with missing lines	Coverage Δ
spock-core/src/main/java/spock/lang/Retry.java	100.00% <ø> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[Vampire]

@leonard84 is this actually the intended and expected behavior?
That only expected failures in the feature method trigger a retry I mean.
I do some UI tests using Geb with Marathon driver and it happens sometimes on GHA that the application cannot be started and thus the driver throws an exception.

This is done in an iteration interceptor before calling proceed, the iteration interceptor is within the retry iteration interceptor due to using global retry extension. But as the error happens there and not during feature method invocation, it does not cause a retry.

[leonard84]

It is the current behavior. I'm not opposed to letting it cover setup as well.

Though if I'm not mistaken, you'll have problems covering cleanup without the method executions appearing in the results.

[AndreasTu]

Maybe we also the the same sentence as in the docu

Suggested change

	* Retry only the feature method execution, setup and cleanup are not running on retries.
	* Retry only the feature method execution, setup and cleanup are not running on retries.
	* If the setup or cleanup is failing, the test fails immediately.

[Vampire]

I don't think it makes sense here.

The sentence in the docs is about the SETUP_FEATURE_CLEANUP mode below and there I already added the sentence like in the docs.

In the ITERATION mode setup and cleanup are not part of the retry, so why should we additionally mention that the test fails if they are failing, they are not affected in any way by the retry anyway in that mode.

[Vampire]

Besides that it is anyway questionable whether this is actually the intended behavior, thus my question above to @leonard84

[leonard84]

It is the current behavior. I'm not opposed to letting it cover setup as well.

Though if I'm not mistaken, you'll have problems covering cleanup without the method executions appearing in the results.