Как настроить arquillian для тестирования проекта войны в Maven, развернув всю войну в WildFly?

Question

Я бы хотел сделать макрос (не микро!) Черным ящиком моей войны на встроенном экземпляре WildFly.

Мой Maven проект выглядит следующим образом

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

Мои arquillian тесты должны отвечать следующим требованиям:

• Развертывание всю войну к серверу приложений в тестах. Сюда входят все производственные классы, все зависимости от выполнения и все файлы src/main/webapp. С точки зрения обслуживания невозможно выполнить микроразвертывания, потому что зависимости классов и jar-зависимостей изменяются очень часто. Поэтому мы не можем перечислять что-либо в развертывании ShrinkWrap.
• Ничего в тесте не жёстко или arquillian.xml , который уже известен по мавена pom.xml. Это включает в себя строки версий, списки зависимостей, списки пакетов или классов, каталоги установки на сервере приложений и т. Д.
• Не используйте более одного модуля maven. Мои тесты для проверки моей войны принадлежат к тестовой папке того же модуля maven, который производит войну.
• Пользователи, которые Checkout мой код должен быть в состоянии так просто запустить тесты:
  • тесты необходимо запустить с IntelliJ после простого открытия pom.xml с IntelliJ.
  • Использовать встроенный контейнер WildFly, поэтому сначала не нужно устанавливать ни один процесс, и сначала необходимо выполнить процесс, и определенно no JBOSS_HOME переменная среды должна быть установлена ​​.
• Меня интересует только проверка черного ящика, поэтому все мои тесты могут работать как клиент.

В теории, все это возможно с Maven распознаватель Arquillian, вставленные контейнеры, @RunAsClient, Maven плагин безотказное, некоторые arquillian.xml магии и много Maven магии. Но на практике я не могу заставить этот материал работать вместе, и я не нахожу документацию, достойную прикрытия этого сценария, поэтому я надеюсь, что кто-то сможет ясно показать, как они могут работать вместе.

Answer 1

Определенно звучит как случай для ShrinkWrap Resolver Maven Importer (не путать с Maven Resolver). Here - некоторые тесты, показывающие его использование.

У меня есть отдельный образец только для случая Gradle Importer (я знаю, что вы используете maven), но тестовая конструкция аналогична here.

У меня нет точного примера, публично доступного как с @RunAsClient, так и с Maven Importer, но у меня есть проект, использующий их вместе с Graphene, и эта комбинация действительно работает :). Как правило, тест должен выглядеть так:

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

Зачем использовать Maven Importer вместо развертывания войны?Война создается после выполнения тестов, это означает, что если война существует во время выполнения теста, то она исходит из предыдущей сборки и устарела.