Testrunner does not like Spock 1.0

[kriegaex]

We use this in our project:

    <dependency>
        <groupId>org.codehaus.groovy</groupId>
        <artifactId>groovy-all</artifactId>
        <scope>test</scope>
        <version>2.4.1</version>
    </dependency>

    <dependency>
        <groupId>org.jboss.arquillian.spock</groupId>
        <artifactId>arquillian-spock-container</artifactId>
        <version>1.0.0.Beta3</version>
        <scope>test</scope>
    </dependency>

    <dependency>
        <groupId>org.spockframework</groupId>
        <artifactId>spock-core</artifactId>
        <scope>test</scope>
        <version>1.0-groovy-2.4</version>
    </dependency>

Obviously the Spock container does not like Spock 1.0. It says:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test (default) on project a.b.c.frontend.gui: Execution default of goal org.apache.maven.plugins:maven-failsafe-plugin:2.18.1:integration-test failed: There was an error in the forked process
[ERROR] java.lang.NoSuchMethodError: org.spockframework.runtime.JUnitDescriptionGenerator.attach()V
[ERROR] at org.jboss.arquillian.spock.ArquillianSputnik.getSpec(ArquillianSputnik.java:181)
[ERROR] at org.jboss.arquillian.spock.ArquillianSputnik.runExtensionsIfNecessary(ArquillianSputnik.java:190)
[ERROR] at org.jboss.arquillian.spock.ArquillianSputnik.getDescription(ArquillianSputnik.java:155)
[ERROR] at org.junit.runners.Suite.describeChild(Suite.java:122)
[ERROR] at org.junit.runners.Suite.describeChild(Suite.java:26)
[ERROR] at org.junit.runners.ParentRunner.getDescription(ParentRunner.java:298)

Update: I also tried this, to no avail:

    <dependency>
        <groupId>org.jboss.arquillian.spock</groupId>
        <artifactId>arquillian-spock-container</artifactId>
        <version>1.0.0.Beta3</version>
        <scope>test</scope>
        <exclusions>
            <exclusion>
                <groupId>org.codehaus.groovy</groupId>
                <artifactId>groovy-all</artifactId>
            </exclusion>
            <exclusion>
                <groupId>org.spockframework</groupId>
                <artifactId>spock-core</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

[bartoszmajsak]

Thanks for the detailed report. It seems that Sputnik runner has been changed. I will take a lookt at it.

[kriegaex]

Well, actually the Spock API has changed too between 0.7 and 1.0, e.g. the lifecycle methods are now no longer single instances but collections. I.e. I tried to change method interceptLifecycleMethods like this:

private void interceptLifecycleMethods(final SpecInfo specInfo, final ArquillianInterceptor interceptor)
{
    for (MethodInfo methodInfo : specInfo.getSetupSpecMethods())
        methodInfo.addInterceptor(interceptor);
    for (MethodInfo methodInfo : specInfo.getSetupMethods())
        methodInfo.addInterceptor(interceptor);
    for (MethodInfo methodInfo : specInfo.getCleanupMethods())
        methodInfo.addInterceptor(interceptor);
    for (MethodInfo methodInfo : specInfo.getCleanupSpecMethods())
        methodInfo.addInterceptor(interceptor);
}

It compiles, but obviously it leads to follow-up problems. Furthermore, your POMs are unclean as well. I needed to change a few things in order to make the project compile. Anyway, the tests are not running because there are follow-up problems, probably with the lifecycle method interceptors. Someone knowing the code base needs to fix it, I could not when taking a quick look.

One more thing with Spock 1.0 is that it no longer supports Groovy 1.x, i.e. the example project for 1.x should be deleted when upgrading to Spock 1.0.

Should I issue a pull request with my half-baked changes, i.e. with a compiling project but with failing tests? I am unsure if it does you any good.

[bartoszmajsak]

Thanks, please make a PR so I can continue based on the work you have already done. Otherwise I would re-do the same ;)

[kriegaex]

Ping. Can you say anything about when you can fix this? Not that it is your problem, but for my Scrum team this is a blocker. I am just saying this FYI.

[bartoszmajsak]

Pong,

sorry for being silent lately. I've been busy with my regular job. I am on holidays now so cannot really dive into this, but I will be back first weekend of May and this is one of the first things for me to look at. With batteries fully re-charged I should be able to help you promptly :)

Cheers,
Bartosz

[kriegaex]

Ping reloaded - 2.5 months. ;-)

[bartoszmajsak]

OMG ! :)

It's coming!

[kriegaex]

Did your brain actually burst? :-P

[bartoszmajsak]

I was soaked in other stuff (regular work) + conference thing. I know it's just an excuse for being lazy, but that was holding me back from releasing it.

I am coming back this weekend so except to have it released by the end of next week. You have my word.

[bartoszmajsak]

Besides this crazy heat outside I spent quite a bit of time analyzing this problem :) It seems that for some reason in-container bits of Spock-Arquillian integration are triggered on the client side which results in pretty meaningless NPE in the logs. I hope to have a solution for that within next few days.

[nate9]

Hey, I've forked kriegaex's fix, and run some tests using Travis. Seems that on Oracle Java 1.7 it seems to throw the NPE's. It seems to not like Inject annotation. Oracle Java 1.8 seems to pass those tests though.

[kriegaex]

@nate9: I am not sure my PR is really a fix. As I said, it only makes the project compile. I cannot even remember the exact type of follow-up problem it caused, but I am pretty sure it did cause runtime problems. Someone knowing the code base (probably Bartosz) needs to fix it.

[ewsachse]

I tried the PR, and it failed on NullPointerExceptions when running Spock-Arquillian tests. I was using Java 1.7 and Groovy 2.4 if that is of any help.

[nate9]

Actually Java 8 doesn't pass the tests, the container runs, but the tests don't seem to do anything :/. They timed out after 10 minutes. Perhaps the container configurations for those tests are outdated?

[ewsachse]

That is good to know. I was actually trying to run tests from my application's project with the fix. No dice. I just rolled Spock back to 0.7-groovy-2.0, but I was hoping to use 1.0. I think we can wait for a fix for now.

[kriegaex]

I repeat: the PR is not a fix, just a starting point for the maintainer to get it fixed a little bit easier than by starting from scratch.

[kriegaex]

1/2 year anniversary. @bartoszmajsak, is there any hope left for me? Or can you tell me how to repair it by myself and provide a better PR?

[bartoszmajsak]

Let's crack open the champagne!

As Spanish say

Lo ultimo que muere es la esperanza

;)

I have had a closer look at this issue in the past but I do not have any conclusions as of yet :( So I cannot really provide any guidance at the moment. I will try to go back to it over the weekend and hopefully fix it or at least give you some hints if you are willing to take over. Apologies.

[kriegaex]

Maybe you can ask the Spock people for guidance in the other ticket I opened and linked to this one a while ago. Probably I am not a big help here. Crossing my fingers and keeping the hope alive for a little longer.

P.S.: Germans say the same, even literally.

[bartoszmajsak]

As far as I know it's not really related to Spock per se, rather how the integration with Arquillian runner is implemented. Somehow it's executed on the client side, which should not be the case. And hence NPEs.

If I hit the wall I will scream and shout here :)

[kriegaex]

Are you in contact with any Arquillian devs? Maybe someone can lend a hand or at least another pair of eyes. My old chemistry teacher used to say: "Knowledge is to know where to find it."

[bartoszmajsak]

Sure. Thanks for your patience.

[lordofthejars]

Hi @bartoszmajsak any good news about this issue?

[bartoszmajsak]

Yes. I almost have it running :)

[lordofthejars]

@bartoszmajsak please tell me you have good news about this :)

[kriegaex]

Ping. :-)

[Steve973]

@kriegaex - I get the same error with your fork:

Exception in thread "main" java.lang.NoSuchMethodError: org.spockframework.runtime.model.SpecInfo.addSetupSpecInterceptor(Lorg/spockframework/runtime/extension/IMethodInterceptor;)V

[kriegaex]

@Steve973: Sorry, I deleted my previous comment when I noticed that your problem was not a build, but a runtime problem. My fork only fixes the Maven build, no actual functionality. Maybe you want to share a testcase for @bartoszmajsak in order to help him reproduce the problem.

[Steve973]

Sorry for the false alarm. The problem was a conflicting version of spock in my dependency chain.

[Steve973]

Is there any reason why ArquillianSputnik would not be present in my container? I am assuming user error again, but I don't see a whole lot of difference between my project's testing setup and that of the examples. But I am using Karaf-remote as my container.

[bartoszmajsak]

If you run JBoss version older than wildfly with Java 8 this is the very
reason it hangs. You should run 7. Not sure if it's cglib but there is some
library which hangs.

Now, can I go back to beer? 😂

Cheers!
On Feb 24, 2016 14:56, "Steve973" notifications@github.com wrote:

Sorry for the false alarm. The problem was a conflicting version of spock
in my dependency chain.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[bartoszmajsak]

I haven't tested with Karaf. Can't really help you much with mobile only 😩

I will be back home Saturday so if you won't be able to fix the problem
till then please give me as much relevant info about your setup as possible
or better share the example on github so I can fork, fix and PR.
On Feb 24, 2016 15:35, "Bartosz Majsak" bartosz.majsak@gmail.com wrote:

If you run JBoss version older than wildfly with Java 8 this is the very
reason it hangs. You should run 7. Not sure if it's cglib but there is some
library which hangs.

Now, can I go back to beer? 😂

Cheers!
On Feb 24, 2016 14:56, "Steve973" notifications@github.com wrote:

Sorry for the false alarm. The problem was a conflicting version of spock
in my dependency chain.

—
Reply to this email directly or view it on GitHub
#18 (comment)
.

[Steve973]

@bartoszmajsak -- I'm working on an example right now. I'm having a bit of trouble with something unrelated to the arquillian spock library because I'm trying to start a managed karaf container and run the tests in there. My use case is to connect to a custom distro that is already running, but the test would be better, of course, if it was more basic and used a fresh distro of karaf. I'll give you a link to my github repo when it's done. If the problem exists only with my particular configuration, at least you could add it (or part of it) to your examples to provide some karaf-specific instructions if they differ at all from the other examples that you have.

[Steve973]

Are any of you getting this either while building the project, or when building against this project's artifacts as dependencies:

[WARNING] The POM for org.jboss.arquillian.spock:arquillian-spock-core:jar:1.0.0.Final-SNAPSHOT is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details
[WARNING] The POM for org.jboss.arquillian.spock:arquillian-spock-container:jar:1.0.0.Final-SNAPSHOT is invalid, transitive dependencies (if any) will not be available, enable debug logging for more details

[kontact-chan]

Where should i find arquillian-spock-container 1.0.0.Final-SNAPSHOT repository.

https://repository.jboss.org/nexus/content/repositories/snapshots/ don't have it anymore.

[fwelland]

Looks like the trail is running cold on this. Is there going to be any movement towards Spock 1.0 and this Arquillian Test Runner?

[bartoszmajsak]

:) At least I'm responding promptly.

I didn't have time over last few months to spend time on this, but I hope to make a release early December.

[fwelland]

oh wow....good to know....

I am tinkering with the spock_1.0 branch -- do you know if that works?

[dchesterman]

Any update here? :)

[JonLally]

This works for me only when I pull the project and create a SNAPSHOT locally.
Can this be released so we can all use it with spock 1.0?

Thanks, Jon

[kriegaex]

Some things work with Spock 1.0, others do not. So the product is not ready for a release yet. P.S.: With 1.1-rc3 being around for a while I guess 1.1-final will soon be available.

[paulk-asert]

Does Spock 1.1 final make any difference?

[jollytoad]

I get the impression that momentum on this has dried up, but is it likely that this runner will no longer be required anyway once arquillian/arquillian-core#147 is complete?

[jollytoad]

I was curious as to whether the support for running Arquillian via test rules rather than test-runner may work in combination with Spock (and its default Sputnik runner rather than the ArquillianSputnilk runner), and I managed to get quite close...

class TestSpec extends Specification {

    @Deployment
    static Archive deployTests() {
        final JavaArchive[] spockArchives = Maven.resolver()
            .resolve("org.spockframework:spock-core:1.1-groovy-2.4")
            .withoutTransitivity()
            .as(JavaArchive.class)

        def archive = ShrinkWrap.create(JavaArchive.class, "tests.jar")

        spockArchives.each { archive.merge(it) }

        return archive
            .addPackages(true, "groovy")
            .addPackages(true, "org.codehaus.groovy")
    }

    @Shared
    @ClassRule
    ArquillianTestClass arquillianTestClass = new ArquillianTestClass()

    @Rule
    ArquillianTest arquillianTest = new ArquillianTest()


    def "blah blah blah"() {
        expect:
        1 == 1
    }

}

The only problem is that the 'feature' descriptions mismatch at run time, a SpecInfo is created and its features filtered in org.spockframework.runtime.model.SpecInfo#filterFeatures, which boils down to
org.junit.runner.manipulation.Filter#shouldRun comparing the descriptions. With the example above i end up with...

desiredDescription: "$spock_feature_0_0(test.TestSpec)"
description: "blah blah blah(test.TestSpec)"

so 'excluded' gets set to true on the feature and skipped.
If I force it back to false in the debugger and allow the test to continue it runs and passes.

I'm not sure if anything further can be done from this, i'm not all that familiar with Spock or the internals of JUnit - but I hope it may be of use to anyone else thinking of pursuing this route.

Sorry if this is an in appropriate place to post this, but I really wasn't sure where else I could effectively pass this onto other folks interested in Spock+Arquillian integration.

[kriegaex]

@bartoszmajsak, is this product dead? I still love Spock & Geb and the next one of my clients is considering using it in connection with Liferay (LR). There is a special Arquillian extension for LR, so there is always the option to use Drone for browser testing, but I would very much prefer to use Spock & Geb instead of JUnit + Drone because I just have much more experience with the former pair and zero with the latter.

Is there anything I can do to move this forward? Is there anyone whom you can hand this project over to or who can at least support you?

[jollytoad]

So, my colleague (and Geb's very own) Marcin Erdmann has taken the reins on this and submitted a PR to arquillian-core to allow Spock test methods to be executed correctly by Arquillian.

See arquillian/arquillian-core#215

[kriegaex]

@jollytoad, can you please elaborate on what exactly that means and how it solves this and other Spock-related problems? Does is mean that

• Arquillian Spock Runner (ASR) is obsolete? If so, how do I run my Spock & Geb tests now?
• it now works with the last version of ASR released on Maven Central?
• it now works with the last snapshot from master or spock_1.0 branch of ASR?

Or is is neither of the above and I need to do something else?

[jollytoad]

So, if the PR is accepted and merged, the ArquillianSputnik testrunner would not be necessary.

You'd be able to use the standard spock Specification and the Arquillian rules instead (see my example above), although you still need to include various extras into the deployment archive, and an ArquillianSpecification (extending the Spock Specification class) for convenience - so we'd probably need some kind of Arquillian Spock extension still, to provide these without everyone having to duplicate stuff, but it should be a whole lot simpler than the current ASR solution.

None of this has been released, it's currently just the PR i've linked to above.

[kriegaex]

Hm, okay. So for now it would not be helpful to compile and run Arquillian with the PR because there would be missing pieces in the jigsaw puzzle. This has been going on for 4 years, so I would like to help this move forward by testing and providing feedback. Your explanation sounds like this is not possible yet.

[bartoszmajsak]

Closing this gives me a weird mix of feeling relieved, excited and embarrassed at the same time.

I really want to thank you all folks for providing input and nagging me to do something with this project (note: it's not a product, but opensource library and never been otherwise). Please give it a try building from master if you wish, but I will cut the release today too so the new version is out.

[bartoszmajsak]

So, if the PR is accepted and merged, the ArquillianSputnik testrunner would not be necessary.

@jollytoad that's correct and should be easy to use when you are mainly focusing on blackbox tests (such as those with Geb). As soon as you want to run that in some sort of application container this extension will help you bundling all required deps.

[bartoszmajsak]

1.0.0.CR1 has been released. Hopefully arrives in Maven Central tonight.

[kriegaex]

Thank you. Looks like some of the tickets you closed are fixed while others are not. See my feedback there.