Tiny idea -- class-level @RunAsClient implies 'testable = false' for all @Deployment-s

[lthon]

Hi,

I started to use Arquillian recently (I'm specifically using Arq 1.0.2.Final and JBoss AS 7.1.1.Final) and somehow, I understood that annotating the class with @RunAsClient is equivalent to marking all @Deployment methods testable=false. But apparently, this isn't true -- if I don't set the @Deployment to be testable=false, the META-INF/MANIFEST.MF file in the deployment archive is augmented a little bit:

Dependencies: org.jboss.modules,deployment.arquillian-service,org.jbos

s.msc

I'm not sure if the archive is altered in some other way. This causes weird failures when playing with the container (it is mode="manual", it is started in a @Before method and then stopped and started again in the @Test). Adding testable=false to the @Deployment makes the archive unaltered and the test OK.

I (think that I) understand what is going on here -- if I have a hybrid test where one method is executed in-container while the other is @RunAsClient, then I obviously want the deployment archive augmented (well, I might not want it for the @RunAsClient test, but then I must not use the same deployment archive). But if I have a test where the whole class is annotated @RunAsClient, then I think it makes sense to make all deployments testable=false automatically.

WDYT?

P.S.: maybe I'm approaching this badly -- is it possible that the added 'Dependencies: ...' stuff is wrong and shouldn't be there at all?

[aslak]

@RunAsClient on Class level is really only available for backward compatabillity with the @RunMode annotation used earlier. Class level should've been deprecated.

@RunAsClient only effects where the Test methods should run, on client side or in container.

@Deployment.testable effects the packaging process (testable = true will prepare the deployment for incontainer support). Since testable=false means don't prepare for in contianer testing, the run mode is automatically switched to RunAsClient as incontainer is not supported.

The change to the Deployment depend on which Protocol is used by the container / defined by the user. E.g. the AS7JMXProtocol  (as you're using above) will add a dependency to the Arquillian Service running in AS7 so it can share some classes and the Servlet Protocol will add a Servlet. This Protocol is used to communicate between the Client and the Container when executing tests in container.

I'm suspecting it might be the Arquillian Service deployment that happens on first request to a Deployment that uses the AS7JMXProtocol and undeployed after Suite that is causing the issues here. Do you have a stack trace?

You might want to try to use the Servlet Protocol instead: https://docs.jboss.org/author/display/ARQ/JBoss+AS+7.1%2C+JBoss+EAP+6.0+-+Remote

@RunAsClient on Class level can be usefull when used combined with Arquillian Warp. Warp uses a hibrid approach where you can test client calls to a server and do in container assertions during the request. Warp requires to modify the Deployment similar to the way a Protocol does, but will normally execute the test methods on the client side. (tho we are looking at exposing a more fine grained control over the how the deployment is changed in the future for corner cases where you only want certain extension types to be active incontainer.)

[lthon]

I know that testable=false implies RunAsClient, I only wanted the relation to be symetric (class-level RunAsClient can safely imply testable=false for all deployments). But if you consider class-level RunAsClient deprecated, then the idea is pointless. Thanks for explanation!

[aslak]

Ladislav Thon wrote:

class-level RunAsClient can safely imply testable=false for all deployments

In the case of Warp it can't.

We might consider the Class Level usage in Warp as a 'hack' due to lack of SPI level support for 'some packaging level between client of incontainer', but... for now it's valid.

[lthon]

Aslak Knutsen wrote:

Ladislav Thon wrote:

class-level RunAsClient can safely imply testable=false for all deployments

In the case of Warp it can't.

Oh, OK then. Still have a lot to learn :-) Thank you!