Support JUnit Rules


#1

Could you guys give this a spin?

An attempt to move the Before/After Arquillian lifecycle to Around Rules. Rules should automatically be ignore if the Before phase LifecycleMethodExecutor is not invoked (e.g. via @RunAsClient)

The After phase LifecycleMethodExecutor is simply ignored. To my knowledge they are never really controlled separately anyway, so it shouldn’t cause any problems.

The missing piece to get full Rule support would be to add a TestEnricher to junit-core that scan for @Rule and re-execute the TestEnricher chain on each Rule found.


#2

Hi,

yeah I’ll try it on reporter with some rule and see if TestResult will be marked as passed in the situation below, that is basically all I need …

    @Rule
    public ExpectedException expectedException = ExpectedException.none();
    
    @Test
    public void testMethod()
    {
        expectedException.except(RuntimeException.class);
        throw new RuntimeException("this is expected");
    }

#3

Test as such works however I am still getting this

    public void observeAfterTest(@Observes After event, TestResult result)
    {
        // when you take method I mentioned earlier
        // result.getStatus() is still Status.FAILED
    } 

I am running that test method with class level @RunAsClient


#4

Are you observing @After in container or on client side? Is this a in container test or pure client side?


#5

tho… missed the line after the code example… :wink:

Let me check


#6

It is pure client test, I have Android container on cp but it @RunAsClient put on test class.

I am observing it on client side having arquillian-junit-standalone on class path. I tried it with junit-container and it is same thing.

Having LocalTestMethodExecutor on cp from junit-standalone, it observes Test event fired from EventTestRunnerAdaptor.test(TestMethodExecutor testMethodExecutor).

TestResult is after that added in NonManagedObserver and returned to Arquillian:285

methodInvoker is called in methodBlock but in case test method eventually succeeds, TestResult from methodInvoker does not update its state from Status.FAILED to Status.PASSED when Status.FAILED was initially set in LocalTestMethodExecutor:61


#7

Yeah, we need to update the TestResult via the RunListener API after it’s done to get the real result.

It should look better with a remote test tho. The container side is now reporting more accurately and the client side Rules are ignored. :slight_smile:


#8

Client side rules would like to get some love too :smile:


#9

So how do you distinguish in between a rule that should be applied on client side and rule that should be applied on server side?

Does @RunAsClient work? Or does it follow testable flag?


#10

Currently follow the same rules as @Before/@After… a combination of @Deployment.testable and @RunAsClient

The next step would be to support @RunOnClient on @Rule and @Before/@After.


#11

Hi,

May I ask what is status of this feature request? Could I expect this being fixed soon?

I have the same usecase as is mentioned here - using the rules and run the tests from the client. I would be happy to have ability to check the test result in my ‘after test’ observer. That would be really handy.

Thanks
Ondra


#12

Could you give 1.1.5.Final-SNAPSHOT a go? Hopefully fixes the issues.

Been attempting to stage it, but for what ever reason Nexus seems to fail at the exact same point in the process right now …


#13

Awesome, it really works. I tried these two use cases and it marks result as passing.

@RunWith(Arquillian.class)
@RunAsClient
public class TestCase {

    @Test
    public void fakeException() throws Exception {
        exception.expect(RuntimeException.class);
        throw new RuntimeException("this is some expected exception");
    }

    @Test(expected = RuntimeException.class)
    public void fakeException2() throws Exception {
        throw new RuntimeException();
    }

}

It would be really cool if ARQ-1804 was resolved in 1.1.5.Final as well in order to cover TestNG to finally move from recorder to something else for a moment …

https://issues.jboss.org/browse/ARQ-1804


#14

Excellent.

I’ll give TestNG a quick look, but in general it’s a completely different beast.

… some time later…

TestNG support for the same behavior included in 1.1.5.Final.


#15

fyi… JUnit covers roughly 90% of the users.