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:
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.pom.xml
. This includes version strings, dependency lists, package or class lists, app server installation directories, etc.pom.xml
with IntelliJ.JBOSS_HOME
environment variable needs to be set first.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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With