Wie richte ich Arquillian ein, um ein Maven War-Projekt zu testen, indem ich den gesamten Krieg auf WildFly embedded setze?

Question

Ich würde gerne Makro (nicht Mikro!) Black Box Tests meines Krieges auf einer eingebetteten WildFly-Instanz durchführen.

Mein Maven Projekt sieht wie folgt aus

<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> 

Meine Arquillian Tests die folgenden Anforderungen erfüllen müssen:

• Bereitstellen des gesamten Krieges auf den App-Server in den Tests. Dies umfasst alle Produktionsklassen, alle Laufzeitabhängigkeiten und alle src/main/webapp Dateien. Aus Wartungssicht ist es unmöglich, Mikrobereitstellungen durchzuführen, da sich Klassenabhängigkeiten und JAR-Abhängigkeiten sehr häufig ändern. Daher können wir in der ShrinkWrap-Bereitstellung nichts aufzählen.
• Sie nichts im Test hart codieren oder arquillian.xml , die bereits von der Maven pom.xml bekannt ist. Dazu gehören Versionszeichenfolgen, Abhängigkeitslisten, Paket- oder Klassenlisten, Installationsverzeichnisse für Anwendungsserver usw.
• Verwenden Sie nicht mehr als 1 Maven-Modul. Meine Tests zum Testen meines Krieges gehören in den Testordner des gleichen maven-Moduls, das den Krieg produziert.
• Benutzer, die meinen Code Kasse müssen in der Lage sein, so einfach die Tests ausführen:
  • Tests von IntelliJ nach den pom.xml mit IntelliJ einfachen Öffnen ausgeführt werden muss.
  • Verwenden Sie eingebettete WildFly-Container, so dass nichts zuerst installiert werden muss, kein Prozess muss zuerst ausgeführt werden und keine JBOSS_HOME Umgebungsvariable muss zuerst festgelegt werden.
• Ich bin nur daran interessiert Test Blackbox, so dass alle meine Tests können laufen als Client.

In der Theorie ist das alles möglich mit Arquillian des Maven Resolver, eingebettete Container, @RunAsClient, Maven Failsafe-Plugin, einige arquillian.xml Magie und viel Maven Magie. Aber in der Praxis kann ich dieses Zeug nicht zur Zusammenarbeit bringen und finde auch keine Dokumentation, die dieses Szenario angemessen abdeckt, also hoffe ich, dass jemand deutlich zeigen kann, wie sie zusammenarbeiten können.

Answer 1

Klingt definitiv wie ein Fall für ShrinkWrap Resolver Maven Importer (nicht mit dem Maven Resolver zu verwechseln). Here sind einige Tests, die seine Verwendung zeigen.

Ich habe eine eigenständige Probe für nur einen Fall von Gradle Importer (Ich weiß, Sie Maven verwenden), aber die Testkonstruktion ist ähnlich here.

Ich habe derzeit kein ganzes Beispiel öffentlich verfügbar mit @RunAsClient und Maven Importeur, aber ich habe ein Projekt mit ihnen zusammen mit Graphene und diese Kombination funktioniert :). Im Allgemeinen sollte der Test wie folgt aussehen:

@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 { 
     ... 
    } 
} 

Warum Maven Importeur anstelle des Kriegseinsatzes verwenden?War wird nach der Ausführung des Tests erstellt, das heißt, wenn der Krieg während der Testausführung existiert, dann kommt er aus dem vorherigen Build und ist veraltet.