[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=12691215#comment-12691215 ] 

Dan Allen commented on ARQ-918:
-------------------------------

I agree we shouldn't break backward compatibility. I'm open to not deprecating the testable attribute either if that's the trade-off for introducing a better attribute name. (It's possible to honor both with a mutually exclusive validation).

I don't agree we can just let it go. New users are having trouble with this attribute and it's a trouble spot in Arquillian we need to smooth out.

I came up with a few more choices, which I think get us even closer:

* attachTestRunner - Indicates whether the test runner infrastructure should be attached (or somehow combined) with the deployment...attaching onto it so that it gets sent to the container w/ the deployment
* testExecutor - Indicates that this deployment will become the test executor inside the container.
* testInContainer - Indicates the tests should be run in container, specifically inside this deployment (hence the location of the attribute), which implies that the test infrastructure must be there.
* supportsInContainerTesting - Although long, this is the heart of what we are saying in all previous passages.

I'd be prepared to move on "supportsInContainerTesting" since it's the clearest point. I'm also feeling strongly about "attachTestRunner" and "testExecutor".

If you want a better name, please let us know which of these names you think are most intuitive...and of course suggest another one if you have one that fits better.
                
> 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