SpecInfoListener.dummySpecIteration uses invalid IterationInfo constructor

[dariuslf]

SpockReportExtension.groovy line 265 def iteration = new IterationInfo( currentRun.feature, [ ] as Object[], 1 )

The constructor was changed some while back. See https://github.com/spockframework/spock/blob/master/spock-core/src/main/java/org/spockframework/runtime/model/IterationInfo.java

There is now a parameter int iterationIndex in second position.

[dariuslf]

Seems to be related to (closed) issue #200 I tried with 2.0-M4-groovy-3.0 and am getting this issue.

[renatoathaydes]

You're getting this with Spock 2.0-M4-groovy-3.0? If so, please attach a spec that can reproduce the issue.

[renatoathaydes]

@dariuslf I see that you're correct, but that code path only executes if there's no current iteration and the error is NOT on the initializer of the spec, and I don't know how I can reproduce that in tests... so if you can give me a spec that shows this error, I can make sure this won't break again by adding a test.

[renatoathaydes]

I fixed the issue in the dev branch but was unable to reproduce the issue as I couldn't get a spec that caused it... would be nice to get one.

[dariuslf]

Great, thanks for that and thanks for your work on this project generally!

I've got a reproduction here. The key is to throw in cleanup spec:

class DemoSpec extends Specification {
    def "Trigger invalid constructor call"() {
        given: "I have a number"
        def j = 3
        when: "I add to the number"
        j += 3
        then: "I have a greater number"
        j > 3
    }

    def cleanupSpec() {
        throw new Exception()
    }
}

[renatoathaydes]

This is very good. I did fix the issue, but when a spec like this has examples and uses @Unroll, we get yet another error due to the "dummy" iteration not containing the correct amount of dataVariables (which is used in the error message, I think). I will try to get rid of that dummy iteration entirely by adding an actual cleanupSpec ERROR to the report (otherwise there's nowhere to report the error as the error is not in any feature or iteration).

[renatoathaydes]

I fixed the second problem, but now I am not sure if a cleanupSpec error should cause the final report to show the Spec as having failed.

Here's what it looks like now when I have a few examples in the test and cleanupSpec throws:

The reason is that when this error happens, all the internal information about the spec has already been computed successfully... so it's a bit tricky to make the test show as having failed, despite the fact that actually displaying the error in the report is easy... relatedly, the statistics file, used to aggregate the results, will have no information about this error (for the same reason - all data has already been gathered when the error happens). Pretty annoying issue.

[renatoathaydes]

IntelliJ shows the error similarly to the above screenshot but it does report the whole spec as having failed, which I think makes sense.

I will have to do a bit more work to achieve this.

[dariuslf]

That's looking good. I encountered this problem with Geb and a selenium grid. Trying to shut down the browser during cleanup suffered an exception and this lead to the problem here.

As long as any exceptions are reported clearly somewhere (as you've already done), I'm not too bothered as to whether the spec is marked as failed. But doing what IntelliJ does probably makes most sense.

[renatoathaydes]

Fixed in the new release: https://repo1.maven.org/maven2/com/athaydes/spock-reports/2.0-RC4/

[dariuslf]

Many thanks for the quick turnaround!