[arquillian-issues] [JBoss JIRA] (ARQ-918) Pick a better name for testable attribute on @Deployment annotation

[Dan Allen (JIRA)]

    [ https://issues.jboss.org/browse/ARQ-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12691974#comment-12691974 ] 

Dan Allen edited comment on ARQ-918 at 5/10/12 3:28 PM:
--------------------------------------------------------

Right on, Jim. I consulted my resident advisor, and she recommended a very similar approach. Here's the resulting proposal.

>From the beginning, Arquillian has always packaged additional services into the deployment. This is the Arquillian magic or juice. Now there are cases when we want to disable some or all of them. So we are starting with all services and working backwards.

Therefore, it seems to make the most sense to explicitly specify which services you want to disable or disallow. That would suggest an "exclude" annotation.

{code}
@Deployment
@ExcludeServices
{code}

I realized that with the Spring extension, we have a new type of Arquillian service, a service deployer. This is an extension that adds the Spring JAR files for you automatically, even when you are doing black-box testing. In that case, you might use:

{code}
@Deployment
@ExcludeServices({TESTING, INSTRUMENTATION}) 
{code}

Rather than an enum, we may want the value of @ExcludeServices to be a String (with a set of built-in constants) so that additional categories can be added w/o changes to Arquillian Core.

Here's the proposed annotation:

{code}
public @interface ExcludeServices {
    String[] value() default {ALL};
}
{code}

Possible values to exclude are:

* ALL
* TESTING (in-container testing, meaning test runner, enrichers, test case, etc)
* INSTRUMENTATION (monitoring, code coverage, callbacks)
* DEPLOYERS (packages extra JAR files for convenience, like Spring or Weld Servlet)

This proposal:

a) implies that Arquillian defaults to adding all services (according to what is on the classpath)
b) makes disabling all services simple, just a raw annotation
c) gives you fine grained control, if needed
d) is consistent w/ existing behavior (the absense of the annotation means add all services)
                
      was (Author: dan.j.allen):
    Right on, Jim. I consulted my resident advisor, and she recommended a very similar approach. Here's the resulting proposal.

>From the beginning, Arquillian has always packed additional services into the deployment. This is the Arquillian magic or juice. Now there are cases when we want to disable some or all of them. So we are starting with all services and working backwards.

Therefore, it seems to make the most sense to explicitly specify which services you want to disable or disallow. That would suggest an "exclude" annotation.

{code}
@Deployment
@ExcludeServices
{code}

I realized that with the Spring extension, we have a new type of Arquillian service, a service deployer. This is an extension that adds the Spring JAR files for you automatically, even when you are doing black-box testing. In that case, you might use:

{code}
@Deployment
@ExcludeServices({TESTING, INSTRUMENTATION}) 
{code}

Rather than an enum, we may want the value of @ExcludeServices to be a String (with a set of built-in constants) so that additional categories can be added w/o changes to Arquillian Core.

Here's the proposed annotation:

{code}
public @interface ExcludeServices {
    String[] value() default {ALL};
}
{code}

Possible values to exclude are:

* ALL
* TESTING (in-container testing, meaning test runner, enrichers, test case, etc)
* INSTRUMENTATION (monitoring, code coverage, callbacks)
* DEPLOYERS (packages extra JAR files for convenience, like Spring or Weld Servlet)

This proposal:

a) implies that Arquillian defaults to adding all services (according to what is on the classpath)
b) makes disabling all services simple, just a raw annotation
c) gives you fine grained control, if needed
d) is consistent w/ existing behavior (the absense of the annotation means add all services)
                  
> Pick a better name for testable attribute on @Deployment annotation
> -------------------------------------------------------------------
>
>                 Key: ARQ-918
>                 URL: https://issues.jboss.org/browse/ARQ-918
>             Project: Arquillian
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Base Implementation
>    Affects Versions: 1.0.0.Final
>            Reporter: Dan Allen
>
> @Deployment(testable = false) sends the wrong message for a testing platform and is subject to a wide variety of interpretations. We need a better name for this attribute.
> The purpose of this attribute is to determine if this deployment should be wrapped up based on the protocol so the test case can be executed inside the container.
> I'd be content if we gave it a very explicit name, even if that name wasn't tremendously fluent. Here are some suggestions:
> * transportsTest : Indicates whether this deployment will transport the test as part of the deployment so the it can be executed inside the container
> * testRunner : Indicates whether this deployment is itself a test runner, which by definition means it will be run inside the container
> * providesTestRunner : Mixed mode tests are possible, so this most accurately indicates whether this deployment will provide an additional test runner inside the container
> * hostsTest : Indicates whether the deployment will be a host to the test, so the test can be run inside the container
> * packageWithTest : Indicates whether this deployment will be packaged with the test and deployed to the server; when false, the deployment is left alone (not packaged with test)
> The hard part is that when the test is run in container, the @Deployment archive, the test and the test infrastructure often go into another archive that's the real deployment. So this is more of a directive of how to handle the @Deployment than it is about what role it will serve directly.
> I think that "testRunner" or "providesTestRunner" are the most clear options of the ones listed above.
> We can support this attribute as an alias to maintain backwards compatibility, marking testable as deprecated.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira