Details
-
Type:
Feature Request
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 1.1.5.Final
-
Component/s: Test Harness Integration
-
Labels:None
Description
Using the JUnit feature @Rule becomes a problem when running against Remote servers since the @Rule is executed both on the Client and Container side.
It works fine in Embedded Containers since the Test is executed in the same VM, but if the Rule is dependent on Container features, the @Test will fail.
Gliffy Diagrams
Issue Links
- is related to
-
ARQ-56
@Before/@After should only be executed on the server side
-
- Closed
-
Activity
- All
- Comments
- Work Log
- History
- Activity
- Links Hierarchy
I stumbled upon this issue when trying to look up something from JNDI within my custom junit rule. And then I saw it is executed twice...
In the end the behavior for the @Rule annotation should be the same as for @Before/@After (execute the rule only on the container if we are in Client mode).
I think so!
Falko M.
added a comment - I stumbled upon this issue when trying to look up something from JNDI within my custom junit rule. And then I saw it is executed twice...
In the end the behavior for the @Rule annotation should be the same as for @Before/@After (execute the rule only on the container if we are in Client mode).
I think so! PS: In my custom rule I try to retrieve the beans that need to be injected into the test instance but they are null at the time the rule runs (= injection has not been performed yet).
It would be great if that could be addressed as well. It worked that way with Spring 3, btw.
Falko M.
added a comment - - edited PS: In my custom rule I try to retrieve the beans that need to be injected into the test instance but they are null at the time the rule runs (= injection has not been performed yet).
It would be great if that could be addressed as well. It worked that way with Spring 3, btw. 
Aslak Knutsen
added a comment - - edited pushed upstream https://github.com/arquillian/arquillian-core/commit/e39433696861f11588180894378c32f795da8085 It seems to me that it is still failing in RunAsClient scenario. Consider this:
@RunWith(Arquillian.class)
|
@RunAsClient
|
public class TestCase
|
{
|
|
|
@Rule
|
public ExpectedException e = ExpectedException.none();
|
|
|
@Test
|
public void test()
|
{
|
e.expect(RuntimeException.class)
|
throw new RuntimeException();
|
}
|
}
|
Observing org.jboss.arquillian.test.spi.event.suite.After and org.jboss.arquillian.test.spi.TestResult still tells me that result.getStatus() == Status.FAILED is true.
I am using
<dependency>
|
<groupId>org.jboss.arquillian.junit</groupId>
|
<artifactId>arquillian-junit-container</artifactId>
|
<scope>test</scope>
|
</dependency>
|
in the test project.
Should I file related jira or client mode was not treated yet?
Thanks
The client side doesn't fail, as far as Rule support it works just fine. 
You're talking about this ARQ-181 which is a separate issue and not related to Rules only. Working on that as we speak. Got it working for either incontainer or runasclient atm, but struggling with both.
Aslak Knutsen
added a comment - The client side doesn't fail, as far as Rule support it works just fine.
You're talking about this ARQ-181 which is a separate issue and not related to Rules only. Working on that as we speak. Got it working for either incontainer or runasclient atm, but struggling with both. 
Hi,
I would like to take a look at this issue. In the end the behavior for the @Rule annotation should be the same as for @Before/@After (execute the rule only on the container if we are in Client mode). Is that correct?