1:48 a.m.
[
https://issues.jboss.org/browse/ARQ-918?page=com.atlassian.jira.plugin.sy...
]
Dan Allen commented on ARQ-918:
-------------------------------
Several suggestions came up that indicate to me I need to clarify what behavior we're
attempting to control.
* testMode = TestMode.CLIENT etc...
* runMode = ArquillianRunMode.IN_CONTAINER|CLIENT|CLIENT_ENRICHED
* Do the 'supports' and 'testing' bookends reinforce the meaning of
'inContainer' that much?
A deployment is "in container" by definition. We aren't trying to control
whether or not its deployed to the container. Otherwise, we wouldn't be defining a
deployment in the first place.
What we are trying to control is whether Arquillian adds its own infrastructure to the
deployment (effectively repackaging it). That infrastructure adds extra services to the
deployment that become available once the deployment is deployed. Those services are (as
of now):
* a service to run tests in-container
* a service to monitor, analyze or execute callbacks on the server-side code
We are not trying to control how the tests are run. That behavior is controlled on the
test class or test method using the @RunAsClient annotation. When absent, the default is
to run the test "in-container" if the deployment supports in-container testing
or "as client" if the deployment does not. (If there are multiple deployments,
@OperateOnDeployment tells Arquillian which deployment to use for that test).
I'll summarize the three ways a deployment is packaged and the behavior it provides:
* Add the test infrastructure to the deployment - capable of running tests in-container
(white box testing)
* Add instrumentation to the deployment - supports client testing w/ knowledge of internal
state (gray box testing)
* Use the deployment exactly as it's defined - supports purely client testing (black
box testing)
With that in mind, I have another proposal for how to control the packaging of these
services:
{code}
@Deployment(testingServices = ALL | INSTRUMENTATION_ONLY | NONE)
{code}
or as a separate annotation
{code}
@Deployment
@TestingServices(NONE)
{code}
ALL could be IN_CONTAINER instead.
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