search

arquillian / arquillian-testrunner-spock

Arquillian Spock TestRunner
Apache License 2.0
30 stars 20 forks source link

Testrunner does not like Spock 1.0 #18

Closed kriegaex closed 4 years ago

kriegaex commented 9 years ago

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 commented 9 years ago

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

kriegaex commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Ping reloaded - 2.5 months. ;-)

bartoszmajsak commented 9 years ago

star-trek-wtf-2 OMG ! :)

It's coming!

kriegaex commented 9 years ago

Did your brain actually burst? :-P

bartoszmajsak commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

@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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

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 commented 9 years ago

Sure. Thanks for your patience.

lordofthejars commented 8 years ago

Hi @bartoszmajsak any good news about this issue?

bartoszmajsak commented 8 years ago

Yes. I almost have it running :)

lordofthejars commented 8 years ago

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

kriegaex commented 8 years ago

Ping. :-)

aslakknutsen commented 8 years ago

Update: We had a look at this issue during JavaOne hackergarten and if my memory serves me we found a solution to it. The only big question mark seems to be a question mark that is present in previous versions as well; The user needs to add a "def spec" method for the Before phase to be triggered at all. @bartoszmajsak is currently away surfing in Hawaii, but I'm sure he'll push the code when he comes home next week. Then we can release a new version and continue the discussion with upstream Spock to see what we can do about the other issue.

bartoszmajsak commented 8 years ago

The issue consists of several problems we have identified. Besides aforementioned by @aslakknutsen before and beforeclass events not being triggered, spock itself changed packaging slightly and during bootstrap it verifies if arbitrary properties have been defined (e.g. spock release version) - that was a tricky one to catch :)

I've have pushed "fixed" code to the new branch. Feel free to give it a try and share your valuable feedback. Once I'm back from my holidays (which is this weekend...) I will work on releasing new version.

kriegaex commented 8 years ago

@aslakknutsen: Before we try this, can you please elaborate a bit on how to do the "def spec" thing in order to get the Before phase triggered? Maybe we need this workaround in our tests.

aslakknutsen commented 8 years ago

@kriegaex Sorry, meant "setup": https://github.com/arquillian/arquillian-testrunner-spock/blob/master/examples/groovy-1.x/src/test/groovy/org/jboss/arquillian/spock/AccountServiceSpecification.groovy#L42

kriegaex commented 8 years ago

For me it does not work. I get the following stack trace:

my.package.wrapper.MyIT  Time elapsed: 20.785 sec  <<< ERROR!
org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: my.module.wildfly-1.20.0-SNAPSHOT.war
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:83)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
    at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
    at org.jboss.arquillian.spock.ArquillianInterceptor.interceptSetupSpecMethod(ArquillianInterceptor.java:49)
    at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:34)
    at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:87)
    at org.jboss.arquillian.spock.ArquillianSputnik.run(ArquillianSputnik.java:145)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
Caused by: java.lang.Exception: "JBAS014803: Duplicate resource [(\"deployment\" => \"my.module.wildfly-1.20.0-SNAPSHOT.war\")]"
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getActionResult(ServerDeploymentPlanResultFuture.java:134)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.getResultFromNode(ServerDeploymentPlanResultFuture.java:123)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:85)
    at org.jboss.as.controller.client.helpers.standalone.impl.ServerDeploymentPlanResultFuture.get(ServerDeploymentPlanResultFuture.java:42)
    at org.jboss.as.controller.client.helpers.standalone.ServerDeploymentHelper.deploy(ServerDeploymentHelper.java:55)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:77)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:64)
    at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:46)
    at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:146)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
    at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
    at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
    at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
    at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
    at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
    at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
    at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
    at org.jboss.arquillian.spock.ArquillianInterceptor.interceptSetupSpecMethod(ArquillianInterceptor.java:49)
    at org.spockframework.runtime.extension.AbstractMethodInterceptor.intercept(AbstractMethodInterceptor.java:34)
    at org.spockframework.runtime.extension.MethodInvocation.proceed(MethodInvocation.java:87)
    at org.jboss.arquillian.spock.ArquillianSputnik.run(ArquillianSputnik.java:145)
    at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:283)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:173)
    at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
    at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:128)
    at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
    at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
    at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
aslakknutsen commented 8 years ago

@kriegaex That just seems to imply that there is an archive deployed with the same name all ready. If you have a clean server to start with, and still get this, the BeforeClass phase might be called twice. you have multiple 'def specSetup' methods?

kriegaex commented 8 years ago

We have no setupSpec methods at all in any of our integration tests. What we have is ShrinkWrap calls like this:

@Deployment
public static WebArchive createTestArchive() {
    PomEquippedResolveStage pom = Maven.resolver().loadPomFromFile("pom.xml");
    File[] pdfbox = pom.resolve("org.apache.pdfbox:pdfbox").withTransitivity().asFile();
    File[] cglib = pom.resolve("cglib:cglib-nodep").withTransitivity().asFile();

    return ShrinkWrap.create(MavenImporter.class, "MyIT.war").
            loadPomFromFile("pom.xml")
            .importBuildOutput().as(WebArchive.class)
            .addAsWebInfResource(EmptyAsset.INSTANCE, "beans.xml")
            .addAsWebInfResource("foo.properties")
            .addClass(PdfTester)
            .addAsLibraries(cglib)
            .addAsLibraries(pdfbox);
}

The thing is that Maven builds my.module.wildfly-1.20.0-SNAPSHOT.war instead of MyIT.war. If I downgrade to Spock 0.7 and the old runner, it works again.

kriegaex commented 8 years ago

Ping! Can I do anything in order to help you track down this issue?

aslakknutsen commented 8 years ago

@kriegaex What? If you downgrade Spock the name of the ShrinkWrap created war change?

bartoszmajsak commented 8 years ago

Could it be that this deployment is triggered twice in your case?

kriegaex commented 8 years ago

Yes, downgrading helped, because with the old Arquillian Spock Container and Spock 0.7 this ShrinkWrap bug did not do any harm, but we hit it after the upgrade. So we upgraded to ShrinkWrap Resolver 2.2.0 (from 2.1.1) and the issue went away. But now we have a new problem:

All our white-box tests fail with errors similar to this one:

java.lang.NullPointerException: Cannot invoke method fooBar() on null object
    at my.package.MyIT.doSomething(MyIT.groovy:120)
    at my.package.MyIT.testSomething(MyIT.groovy:132)

The "null object" in question is declared in the Spock test like this:

@EJB
MyService myService

We also have this section in the test:

@RunWith(ArquillianSputnik)
class MyIT extends Specification {

    @Deployment
    public static WebArchive createTestArchive() {
        PomEquippedResolveStage pom = Maven.resolver().loadPomFromFile("pom.xml");
        File[] pdfbox = pom.resolve("org.apache.pdfbox:pdfbox").withTransitivity().asFile();
        File[] cglib = pom.resolve("cglib:cglib-nodep").withTransitivity().asFile();

        return ShrinkWrap.create(MavenImporter.class, "MyIT.war").
                loadPomFromFile("pom.xml")
                .importBuildOutput().as(WebArchive.class)
                .addAsWebInfResource(new File("src/test/resources/beans.xml"), "beans.xml")
                .addClass(PdfTester)
                .addClass(AaaIT)
                .addClass(BbbIT)
                .addClass(FooMock)
                .addAsLibraries(cglib)
                .addAsLibraries(pdfbox);
    }
    // (...)
}
bartoszmajsak commented 8 years ago

Do you also have following in place?

def setup() {
   assert myService != null
}
aslakknutsen commented 8 years ago

Right, that is where the spec method came in. Try to add a empty one..

kriegaex commented 8 years ago

Okay, I had forgotten to unstash the setup() methods. This issue is fixed by adding the methods everywhere. Can I expect this to be fixed before the next release?

But now I have the next issue. It seems to be a regression with respect to the previous version: I can see in my logs that after the first integration test my artifact "smoke.ear" is never undeployed, so each subsequent test (using the very same artifact name) runs into 

java.lang.Exception: "JBAS014803: Duplicate resource [(\"deployment\" => \"smoke.ear\")]"

Do we also have a lifecycle problem with teardown, not just with setup?

Should I open a new ticket for this issue or can you answer here?

bartoszmajsak commented 8 years ago

Might be the very same reason. Let me investigate. I will keep you posted.

kriegaex commented 8 years ago

Just an idea: Do you think, temporarily adding an empty cleanup() or cleanupSpec() method would help with the undeployment issue, triggering the tear-down phase, just like the empty setup() helped with the other one?

bartoszmajsak commented 8 years ago

It might. I thought you have tried that already :)

kriegaex commented 8 years ago

It does not really help. @bartoszmajsak, could you identify any root causes or even fix them? Is there a functioning workaround for now?

bartoszmajsak commented 8 years ago

I pushed the fix for "undeploy not being invoked" problem. Before we do a release I really would love to fix two remaining issues:

Working hard on it.

kriegaex commented 8 years ago

I totally agree. Gonna test this first of three fixes tomorrow morning, unless my duties as a Scrum coach point me in another direction. Thanks for all your hard work. I am glad we get some traction on these issues, I appreciate it very much.

kriegaex commented 8 years ago

Hey, we reached a milestone: Disregarding our code-duplicating workarounds for the two issues mentioned in your previous comment, for the first time ever we have just had a green build for our ITs with Spock 1.0. The undeployment issue seems to be resolved. :-)

bartoszmajsak commented 8 years ago

thats-the-way-i-like-it

Hopefully the others will be fixed soon.

NagyGa1 commented 8 years ago

Works for me, with the workaround of dummy setup method, tks.

bartoszmajsak commented 8 years ago

The solution to avoid dummy setup method is to use extension together with the interceptors. I am working on it.