Unable to have setup() in both class and trait without spock-junit4 module

[szpak]

Issue description

Spock 2.0-M3 removed native support for @Before/@After/... annotations from JUnit 4. As a result it is no longer possible to use them without the spock-junit4 module. Unfortunately the same type of a fixture method (e.g. setup()) cannot be used simultaneously in the tests specification and a trait.

How to reproduce

class Legacy142InegrationTest extends Specification implements TimeResetGuardian {

    def cleanup() {
        //some spec specific cleanup
    }
...
}

trait TimeResetGuardian {
    def cleanup() {
        //resets global time variable to "now" in poorly written legacy integration tests
    }
}

Additional comment

Calling cleanup() from a specification class is not permitted in Spock. The method in a trait could have some other name, but it would be error-prone to (in addition) require to call it from the cleanup method in the specification.

This is one of the cases where is might be useful to do some generic setup/cleanup in traits. Maybe we could have some alternative mechanism for the fixture methods?

[merscwog]

Just to ensure I understood the issue, and try some permutations on possible workarounds, I attempted to recreate the issue as stated, but at least with a local built master snapshot or published 2.0-M2, with either groovy 3 or groovy 2.5, I get the below compiler complaint:

Legacy142IntegrationTest.groovy: 4: The method cleanup should be public as it implements the corresponding method from interface TimeResetGuardian
. At [4:3]  @ line 4, column 3.
     def cleanup() {
     ^

1 error

Explicitly specifying public as part of the signature changes nothing, which makes sense since public is implied. My guess is that spock is making that method implicitly private, so it should never work.

Is the inability to override a trait cleanup/setup method part of the overarching issue?

Assume class Parent, class Child, and trait Trait, then consider:

trait Trait { def cleanup() { // fine } }
class Parent extends Specification { def cleanup() { // also fine } }
class Child extends Parent implements Trait { }

This compiles and calls Trait.cleanup() before Parent.cleanup(). Of course, once a trait is applied to a class, then nothing derived from that class would ever be able to utilize the same workaround though.

As to what spock-specific-behavior traits should have in the future, a few choices are to never let them specify setup/teardown methods; allow them to specify setup/teardown methods, but alter the method name to something internal (although should it always get invoked or only if implementing class or derived children never override it?); or provide an annotation specifically for traits (and java interfaces with default methods? and possibly even any specification class) to signify test lifecycle hook methods.

[leonard84]

Spock doesn't officially support traits due to the fact that groovy doesn't support traits with other AST transforms (http://docs.groovy-lang.org/docs/latest/html/documentation/#_compatibility_with_ast_transformations)

Traits are not officially compatible with AST transformations. Some of them, like @CompileStatic will be applied on the trait itself (not on implementing classes), while others will apply on both the implementing class and the trait. There is absolutely no guarantee that an AST transformation will run on a trait as it does on a regular class, so use it at your own risk!

Furthermore, there would be no clear order in regards to which setup method gets called if you implement multiple traits, or if you follow groovys default conflict resolution only the setup of the last declared trait would be used.