[arquillian-issues] [JBoss JIRA] (ARQ-918) Pick a better name for testable attribute on @Deployment annotation
Samuel Santos (JIRA)
jira-events at lists.jboss.org
Thu May 10 20:38:18 EDT 2012
[ https://issues.jboss.org/browse/ARQ-918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12692011#comment-12692011 ]
Samuel Santos edited comment on ARQ-918 at 5/10/12 8:37 PM:
------------------------------------------------------------
Do we want to continue supporting "mixed-mode"?
Currently, this is possible doing something like this:
{code}
@RunWith(Arquillian.class)
public class ExampleIT {
@Deployment
public static WebArchive createDeployment() {
// ...
}
@Test
public void inContainerTest() {
// ...
}
@Test
@RunAsClient
public void clientTest(@ArquillianResource URL baseURL) {
// ...
}
}
{code}
was (Author: Silenius):
Do we want to continue supporting "mixed-mode"?
Currently, this is possible doing something like this:
{code}
@RunWith(Arquillian.class)
public class ExampleIT {
@Deployment
public static WebArchive createDeployment() {
// ...
}
@Test
public void InContainerTest() {
// ...
}
@Test
@RunAsClient
public void ClientTest(@ArquillianResource URL baseURL) {
// ...
}
}
{code}
> 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
More information about the arquillian-issues
mailing list