spock: MissingMethodException after update Spock itself to junit-bom:5.6.0-RC1

Issue description

Several own Spock- tests started to fail after upgrade junit-bom from 5.5.2 to 5.6.0-RC1 (master) with:

groovy.lang.MissingMethodException: No signature of method: static spock.util.EmbeddedSpecRunner.tests() is applicable for argument types: () values: []

It would be good to make Spock junit-5.6 (Platform 1.6.0) compatible.

E.g.

method name can still contain parentheses

Condition failed with Exception:

result.tests().started().list().testDescriptor.displayName == ["an actor (named fred) age 30"]
|      |
|      groovy.lang.MissingMethodException: No signature of method: static spock.util.EmbeddedSpecRunner.tests() is applicable for argument types: () values: []
|      Possible solutions: use([Ljava.lang.Object;), getAt(java.lang.String), use(java.util.List, groovy.lang.Closure), use(java.lang.Class, groovy.lang.Closure), wait(), wait(long)
|      	at org.spockframework.smoke.parameterization.UnrolledFeatureMethods.method name can still contain parentheses(UnrolledFeatureMethods.groovy:320)
<spock.util.EmbeddedSpecRunner$SummarizedEngineExecutionResults@314708ce results=org.junit.platform.testkit.engine.EngineExecutionResults@50706160>

	at org.spockframework.smoke.parameterization.UnrolledFeatureMethods.method name can still contain parentheses(UnrolledFeatureMethods.groovy:320)
Caused by: groovy.lang.MissingMethodException: No signature of method: static spock.util.EmbeddedSpecRunner.tests() is applicable for argument types: () values: []
Possible solutions: use([Ljava.lang.Object;), getAt(java.lang.String), use(java.util.List, groovy.lang.Closure), use(java.lang.Class, groovy.lang.Closure), wait(), wait(long)
	... 1 more

All the tests seem to be related to parameterization.

How to reproduce

Bump junit-bom to "org.junit:junit-bom:5.6.0-RC1" and call gw check.

Additional Environment information

OpenJDK 11.0.5, Linux, spock from master

Additional information

Failed tests

    FeatureMethods. are nevertheless reported with their original name
    FeatureMethods. can have names containing any characters in embedded specs
    PendingFeatureExtensionSpec. @PendingFeature includes reason in exception message
    RequiresExtension. verifyExecution
    DataTables. cell references are evaluated correctly in the method's name
    UnrolledFeatureMethods. can unroll a whole class at once
    UnrolledFeatureMethods. expressions in naming pattern that can't be evaluated are prefixed with 'Error:'
    UnrolledFeatureMethods. if creation of a data provider fails, feature isn't unrolled
    UnrolledFeatureMethods. iterations of an unrolled feature foo are named foo[0], foo[1], etc.
    UnrolledFeatureMethods. method name can act as naming pattern
    UnrolledFeatureMethods. method name can still contain parentheses
    UnrolledFeatureMethods. method-level unroll annotation wins over class-level annotation
    UnrolledFeatureMethods. naming pattern in @Unroll annotation wins over naming pattern in method name
    UnrolledFeatureMethods. naming pattern may refer to data variables
    UnrolledFeatureMethods. naming pattern may refer to feature name and iteration count
    UnrolledFeatureMethods. naming pattern supports property expressions
    UnrolledFeatureMethods. naming pattern supports zero-arg method calls
    UnrolledFeatureMethods. variables in naming pattern whose value is null are replaced correctly

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 17 (17 by maintainers)

Commits related to this issue

Most upvoted comments

@Vampire I was thinking about something like that with reflection in my previous message sent in the same time as your 😃.

There is a plan to release M3 “soon” with (in majority) the great set of changes made by @Vampire related to unrolling/parameterize tests.

Where “soon” depends on JUnit releasing 5.7.0 first.

Thanks, I will fix it.

@henrik242 Could you create a new issue to try to cover it?

Yup: https://github.com/spockframework/spock/issues/1148

4 months? 😃

Ooops, sorry. I believe I saw December 15th or something somewhere. I’m probably delusional from too much home office. 😉

4 months? 😃

spock-2.0-M2 on Feb 10 d551442

There is a plan to release M3 “soon” with (in majority) the great set of changes made by @Vampire related to unrolling/parameterize tests.

@szpak I guess this should be rather easy to improve, especially as the runner is written in Groovy? If you replace the EngineExecutionResults occurrences by duck-typing, it is not missing anymore. Then the left problem is that EngineTestKit is missing. But that is not part of any method signature, so you shouldn’t get any missing method exception, but hopefully a meaningful error that that class is not found.

Maybe even better like we warn meaningfully about missing Objenesis and so on, would be to then check in doRunRequestInner whether the EngineTestKit class is present and otherwise give a meaningful warning that suggests the dependency that is missing. wdyt?

Spock-2.0-M2 was just released with the quickfix