Arquillian Test Packaging Scenarios

This page documents the various approaches to packaging a test archive (via ShrinkWrap).

 

1. Full test classpath

 

Run Arquillian using the project's full test classpath (we can think of it as the Maven test classpath--or the kitchen sink). This comes down to effectively transporting the test classpath into the container and executing the selected tests remotely.

 

The problem with the Maven test classpath is that when the test are run, Maven dumps in the whole test classpath into the kitchen sink. It's fine to have all of the main classpath in there, because those classes have to work together. But you don't assume that all of your test classes are going to play together at once. Typically, when you are working on a test, you only want to introduce certain additional classes because those are the overrides and helpers that serve the test scenario.

 

Hence, the next two options.

 

2. Project artifact (main classpath)

 

Run an Arquillian test against the project artifact. This would mean publishing the artifact from the main classpath as a library on which the test depends, but getting to select which test classes get included (your @Alternative beans and such).

 

Also, #2 is considerably more valuable than #1 when you are dealing with CDI since each test case is potentially going to need to activate different @Alternative beans (or overrides of any other sort). Which means for each test class you need:

 

 

  • a separate bootstrap of CDI (which Arquillian gives you for free) and
  • a different beans.xml (which you are going to need to do through ShrinkWrap packaging).

 

 

You could get away with having the whole test classpath + a beans.xml per test class. But if you are going to do that, you might as well just keep going an only include the test classes you need/want. Regardless of what you choose, we'll make sure Arquillian is flexible enough to go to either extreme.

 

3. Micro-deployment

 

Take the surgical approach of constructing a custom archive to executing an in-container test with the granularity of your choosing (you select only the classes you want to participate in the test).