My understanding is that the only things in a @RunWith(Arquillian.class) test that should run outside the container are:
- The test class static and instance initializer blocks and variable initializers, if any
- The test class ctor and any superclass ctors
- The @Deployment method and anything it calls
No @Test methods should run outside the container, and my understanding is that neither should @Before or @BeforeClass. If they seem to be running outside the container, it'd be a good idea to put together a minimal self-contained test case and submit a bug report. Make sure you're testing against Arquillian 1.0.0.Final (or a newer snapshot).
(3) Probably stems from things running outside the container that shouldn't.
For #3, it does appear that @BeforeClass and @Before are both running inside the container but Component.getInstance still fails. I assume there's some Seam initialization done before test execution that isn't happening for @BeforeClass annotated methods. I'm looking for some way to do that initialization myself if that's possible.
I'm verifying that we're inside the container using the code below:
private boolean runningInContainer()
new InitialContext( ).lookup( "java:comp/env" );
catch (NamingException ex)
The current rules for JUnit are:
* BeforeClass / AfterClass are ALWAYS and ONLY executed on the Client side.
** Class level state is not keept alive InContainer between @Test, so BeforeClass/AfterClass == Before/After. When doing in container testing the whole test framework lifecycle will be reexecuted pr @Test on the client.
* Before / After are executed depending on the @Test's RunMode, executed on Client side if @Test run on client.
Note: TestNG does currently not give us the option to 'cancel' @BeforeXX|@AfterXX calls, so here they will be executed both on client and incontainer.
We're using TestNG and we're seeing basically what you indicated - @BeforeClass executing both in the container and the client and also running once per test. Our problem is that we've got hundreds of TestNG tests that we're converting to use Arquillian and JBoss AS 7 that currently use the @BeforeClass annotation to setup test data in the database (used by all @Tests in the class). We need some mechanism to do this with Arquillian where Component.getInstance() will work. For now, our really hacky solution is to override the run() method on Arquillian and do this:
private static AtomicBoolean hasSetupComponentsRun = new AtomicBoolean( false );
public void run(final IHookCallBack callback, final ITestResult testResult)
if ( runningInContainer() && hasSetupComponentsRun.compareAndSet( false, true ))
super.run( callback, testResult );
1 of 1 people found this helpful
one 'option' would be to move to something like the persistence extension, https://github.com/arquillian/arquillian-extension-persistence that knows a bit more about when it needs to run..
of course that doesn't help you in the case of having your current test suite just work..
Or you could replace @BeforeClass with your own annotation, e.g. @Setup and add a little Arquillian extension that handle that annotation specifically..
Thanks for the clarification. I didn't realise @BeforeClass and @AfterClass ran outside the container. That's quite handy, actually, when combined with @Before and @After currently taking over their roles in-container.
OTOH, @BeforeClass and @AfterClass exist to allow expensive setup to be done only once, and it sounds like there's no way to do that at the moment. Given that, is it a good idea to get people used to using them for outside-container work when you may want to support them being run in-container if/when Arq is able to support running multiple @Test methods in one go?
Craig, yea matching client and incontainer lifecycles has been proposed: https://issues.jboss.org/browse/ARQ-350
Another open issue is support for controlling where a Before/After run and specially in a mix runmode / multi contianer setup it starts to get a bit hairy.. https://issues.jboss.org/browse/ARQ-351
A API write up from a while back: http://pastebin.com/WeVnJwzA
Arquillian is some what tied to what the Test Framework we integrate with allow, and we're starting to strech the limits. Implementing some these feature might take us over the fine line of integration vs hacking.