How to configure arquillian to test the maven military project, deploying the entire war in WildFly?

Question

I would like to make a macro (not micro!) A black box of my war on an embedded instance of WildFly.

My maven project is as follows

<project> ... <packaging>war</packaging> <!-- Lots of classes in src/main/webapp and files in src/main/webapp --> <dependencies> <!-- Lots of compile/runtime dependencies that change very frequently --> <!-- Lots of test dependencies that change very frequently --> </dependencies> </project> 

My Arkillian tests must meet the following requirements:

• Deploy the entire war on the application server in tests. This includes all production classes, all execution dependencies, and all src/main/webapp files. From a maintenance point of view, it is not possible to perform micro-deployments, because class dependencies and jar dependencies change very often. Therefore, we cannot list anything in a ShrinkWrap deployment.
• Do not try to copy anything into test or arquillian.xml , which is already known by maven pom.xml . This includes version lines, dependency lists, package or class lists, application server installation directories, etc.
• Do not use more than one maven module . My tests to test my war belong to the test folder of the same maven module that produces the war.
• Users who test my code should be able to just run tests:
  • Tests should run from IntelliJ after simply opening pom.xml using IntelliJ.
  • Use the built-in WildFly container, so you do not need to install a process first, you do not need to start the process first, and definitely no JBOSS_HOME environment variable must be set .
• I'm only interested in black box testing, so all my tests can run as a client.

In theory, all this is possible with the Arquillian Maven resolver, built-in containers, @RunAsClient , maven fault-tolerant plugin, some arquillian.xml magic and a lot of maven magic. But in practice, I can't get these things to work together, and I can't find documentation that fits this scenario decently, so I hope someone can clearly show how they can work together.

Answer 1

Definitely sounds like a case for the ShrinkWrap Resolver Maven Importer (not to be confused with the Maven Resolver). Here are some tests showing its use.

I have a separate sample only for the case of the Gradle Importer (I know that you are using maven), but the test design is similar here .

I don't have an exact example publicly available with both @RunAsClient and Maven Importer, but I have a project that uses them with Graphene , and this combination works :). Typically, the test should look like this:

 @RunWith(Arquillian.class) public class SomeControllerIT { @Deployment public static WebArchive createDeployment() { return ShrinkWrap.create(MavenImporter.class).loadPomFromFile("pom.xml").importBuildOutput() .as(WebArchive.class); } @Test @RunAsClient public void shouldDoSth() throws Exception { ... } } 

Why use Maven Importer instead of launching a war? The war is created after the tests are completed, which means that if the war exists during the test, it comes from the previous assembly and is outdated.