How do I setup arquillian to test a maven war project by deploying the entire war to WildFly embedded? - wildfly

Question

I 'd like to do macro (not micro!) black box testing of my war on an embedded WildFly instance.
My maven project looks like this
<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 arquillian tests need to fulfill the following requirements:
Deploy the entire war to the app server in the tests. This includes all production classes, all runtime dependencies and all src/main/webapp files. From a maintenance perspective it's impossible to do micro deployments because class dependencies and jar dependencies change very frequently. So we cannot enumerate anything in the ShrinkWrap deployment.
Don't hardcode anything in the test or arquillian.xml that is already known by the maven pom.xml. This includes version strings, dependency lists, package or class lists, app server installation directories, etc.
Don't use more than 1 maven module. My tests to test my war belong in the test folder of the same maven module that produces the war.
Users that checkout my code need to be able so simply run the tests:
Tests needs to run from IntelliJ after simply opening the pom.xml with IntelliJ.
Use WildFly embedded container, so nothing needs to be installed first, no process needs to be run first and definitely no JBOSS_HOME environment variable needs to be set first.
I am only interested in black box testing, so all my tests can run as client.
In theory, this is all possible with Arquillian's Maven resolver, embedded containers, #RunAsClient, maven failsafe plugin, some arquillian.xml magic and a lot of maven magic. But in practice, I cannot get that stuff to work together, nor do I find any documentation that covers this scenario decently, so I am hoping someone can clearly show how they can work together.

Answer 1

Definitely sounds like a case for ShrinkWrap Resolver Maven Importer (not to be confused with the Maven Resolver). Here are some tests showing its usage.
I have a standalone sample for just a case of Gradle Importer ( I know you're using maven ), but the test construction is similiar here.
I don't have currenly a whole example publically available with both #RunAsClient and Maven Importer but I have a project using them together with Graphene and this combination do work :). Generally the test should look like:
#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 to use Maven Importer instead of the war deployment? War is created after tests execution, this means that if the war exists during test execution, then it comes from previous build and is outdated.