[JBoss JIRA] Created: (ARQ-126) rename RunModeType.REMOTE to RunModeType.IN_CONTAINER
by Dan Allen (JIRA)
rename RunModeType.REMOTE to RunModeType.IN_CONTAINER
-----------------------------------------------------
Key: ARQ-126
URL: https://jira.jboss.org/jira/browse/ARQ-126
Project: Arquillian
Issue Type: Bug
Affects Versions: 1.0.0.Alpha2
Reporter: Dan Allen
I think that the combination of the terms LOCAL and REMOTE in the RunModeType enum is confusing. RunModeType is attempting to describe where the test runs in relationship to the test runner. In that case, the terms are defensible.
LOCAL = test is local to the test runner (same JVM)
REMOTE = test is remote from the test runner (different JVM)
In the case of LOCAL, the test must use remote communication to invoke the code under test. This is where we overuse the term "remote". The term "remote" implies remote communication, but it's not clear what is remote from the standpoint of the test writer. We are describing internal behavior. And besides, REMOTE isn't entirely accurate since in embedded containers, no remote communication is used.
It's more natural to describe where the test is in relation to the code under test. In that case, local means that the test case stays behind. The other term would be in-container, which may or may not be remote. It's about the packaging. The test is with the test code executing in the container.
I'd like to propose these constants instead:
public enum RunModeType
{
/**
* In LOCAL mode, the @Deployment is processed and deployed to the Container,
* but the test is not executed inside the container. It's local to the test runner.
*/
LOCAL,
/**
* In IN_CONTAINER mode, the @Deployment is processed and deployed to the container along side the test
* case and the test case is executed inside the container.<br/>
* This is the default mode when none specified.
*/
IN_CONTAINER
}
Perhaps I'm just thinking about it wrong, but I just can't get my mind to believe that @RunMode(REMOTE) means that the test case is running in the container. I get how it is technically correct, but human tendency leads me to believe we are going to have to constantly clarify this. @RunMode(IN_CONTAINER) makes it clear that the test is getting relocated to the container.
(I'm even open to changing LOCAL to NORMAL if you think it helps the terminology)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (ARQ-70) Support Method argument injection
by Aslak Knutsen (JIRA)
Support Method argument injection
---------------------------------
Key: ARQ-70
URL: https://jira.jboss.org/jira/browse/ARQ-70
Project: Arquillian
Issue Type: Feature Request
Reporter: Aslak Knutsen
Assignee: Aslak Knutsen
TestEnrichers should be extended to support method argument injection.
{code}
@Test
public void shouldBeAbleToInjectArguments(@Resource, @EJB, MyCDIBean) throws Exception
{
}
{code}
e.g:
{code}
public interface TestEnricher
{
/**
* Extension point to add features to the test method arguments.
*
* IE. Argument injection
*
* @param method
* @return Object[] that match the Field[] indexes. Return null at a specific index value if it can't be handeled.
*/
Object[] resolve(Method method);
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months
[JBoss JIRA] Created: (ARQ-69) Redesign the test framework adaptor
by Aslak Knutsen (JIRA)
Redesign the test framework adaptor
-----------------------------------
Key: ARQ-69
URL: https://jira.jboss.org/jira/browse/ARQ-69
Project: Arquillian
Issue Type: Task
Components: Core, Documentation, JUnit, TestNG
Reporter: Aslak Knutsen
Assignee: Aslak Knutsen
Too much of the Arquillian core responsibility is handed out to the Test Framework integration code. Redesign to a more event/lifecycle based integration.
The DeployableTestBuilder should return a appropriate impl depending on in container or not.
{code}
public interface DeployableTestRunner
{
public void beforeSuite() throws LifecycleException
public void afterSuite() throws LifecycleException
public void beforeClass(Class<?> testClass) throws DeploymentException
public void afterClasss(Class<?> testClass) throws DeploymentException
public void before(Class<?> testClass, Method testMethod)
public void after(Class<?> testClass, Method testMethod)
public TestResult test(TestMethodExecutor testMethodExecutor)
}
{code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 7 months