Allow `@OperateOnDeployment` on types

[nlisker]

@OperateOnDeployment in only allowed on methods, fields, and parameters. Often, a class wants to use the same deployment for all its methods. It would be convenient to apply the class-level annotation on all methods.

[mskacelik]

If I understand correctly, you have in mind something like this use case?

@ExtendWith(ArquillianExtension.class)
@OperateOnDeployment("implicit")
class SomeTestCase {

    @Deployment(name = "implicit")
    public static WebArchive createDeploymentOne() {
        // ...
    }

    @Deployment(name = "explicit")
    public static WebArchive createDeploymentTwo() {
        // ...
    }

    @Test
    // OperateOnDeployment("implicit")
    void testOne() {
        // ...
    }

    @Test
    // OperateOnDeployment("implicit")
    void testTwo() {
         // ...
    }

    @Test
    @OperateOnDeployment("explicit") // OVERRIDES `@OperateOnDeployment("implicit")`
    void testThree() {
         // ...
    }
}

I think that, on paper, sounds reasonable, and might not be too difficult to implement/test (knocking on the wood). I would like to hear what other maintainers think of this, since I barely use @OperateOnDeployment. Maybe Rado, since he is working with multiple deployments quite often, but he is on PTO currently.

[nlisker]

Yes, that's what I meant. In large business applications multiple deployments are not uncommon (or at least shouldn't be if the design is correct).

Also yes, as a new feature, it requires some discussion.

[rhusar]

For WF this would be somewhat useful.

Brief search, there are ~38 test classes (IIOP, multinode, clustering, Elytron, etc.) where the same @OperateOnDeployment("client") or similar is on every method which a class-level annotation would eliminate so ~100 repetitive annotations. Another 54 single-use files can get a minor clarity improvement if we moved it to the class level.

For clustering tests specifically with multi-deployment parameter injection (the DEPLOYMENT_1/DEPLOYMENT_2 URL pattern) these are inherently per-parameter and WOULD NOT benefit from this clearly.

So, if it's not too convoleted to implement, not a breaking change since we are adding behavior, I think this could fly. Lets see what @jamezp thinks too.

[rhusar]

Uuuum, this fix appears to be extremely trivial - we just have to extend org.jboss.arquillian.container.test.impl.client.ContainerEventController#locateDeployment with 2nd attempt to method.getDeclaringClass().isAnnotationPresent(OperateOnDeployment.class) after making the annotation support types and let if be inherited.

I ll just submit a POC.

[rhusar]

POC #887