Arquillian и Open Liberty требуют существующей установки?

Я знаком с Tomcat/TomEE и тестирую приложения с помощью Arquillian. Сейчас были переходят на Open Liberty. Я вижу, что есть модуль для Arquillian, использующий встроенную Open Liberty, но, похоже, для этого требуется существующая установка Open Liberty, путь которой указан в конфигурации. Это делает его непереносимым и, следовательно, непригодным для автоматизированного тестирования, поскольку установка должна находиться по тому же пути. Arquillian и TomEE автономны, не требуют установки. Поэтому мой вопрос: почему это невозможно с Open Liberty? И планируется ли это в будущем?

Для справки, вот как вы используете Arquillian с TomEE/Tomcat:

<arquillian xmlns:xsi = "http://www.w3.org/2001/XMLSchema-instance"
    xmlns = "http://jboss.org/schema/arquillian"
    xsi:schemaLocation = "http://jboss.org/schema/arquillian http://www.jboss.org/schema/arquillian/arquillian_1_0.xsd">
    <container qualifier = "tomee" default = "true">
        <configuration>
            <property name = "httpPort">-1</property>
            <property name = "stopPort">-1</property>
            <property name = "users">user=pass</property>
        </configuration>
    </container>
</arquillian>

Как видите, нет пути к локальной установке, необходимой для запуска тестов. Единственное, что вам нужно сделать, это добавить пару зависимостей Maven в область test, которые подключаются к TomEE (встроенному). Если бы то же самое сработало для Open Liberty, было бы здорово.

Можете ли вы предоставить немного больше информации о встроенном контейнере Open Liberty, о котором вы говорите? Официально мы предлагаем только управляемый и удаленный контейнер: github.com/openliberty/liberty-arquillian Если под «присутствовать по одному и тому же пути» вы подразумеваете, что он должен быть доступен через файловую систему, это правильно в случае управляемого контейнера. Для удаленного контейнера вы можете разместить Liberty в другом месте и подключить/запустить тесты с помощью JMX.

Charles 28.01.2019 19:39
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
1
564
3
Перейти к ответу Данный вопрос помечен как решенный

Ответы 3

Если вы посмотрите на https://github.com/OpenLiberty/open-liberty/blob/integration/dev/com.ibm.ws.microprofile.config.1.2_fat_tck/publish/tckRunner/tck/src/test/resources/arquillian.xml вы увидите пример arquillian.xml, который устанавливает $wlpHome

 <property name = "wlpHome">${wlp}</property>

из переменной окружения $wlp. («wlp» — сокращение от Websphere Liberty Profile)

Здесь переменная wlpHome используется в управляемом/локальном контейнере: https://github.com/OpenLiberty/liberty-arquillian/blob/42cb523b8ae6596a00f2e1793e460a910d863625/liberty-managed/src/main/java/io/openliberty/arquillian/managed/WLPManagedContainer.java#L224

Примером, который делает это динамически, является настройка системное свойство ${wlp} здесь: https://github.com/OpenLiberty/open-liberty/blob/95c266d4d6aa57cf32b589e7c9d8b39888176e91/dev/fattest.simplicity/src/componenttest/topology/utils/MvnUtils.java#L161

Если у вас есть еще вопросы, пишите их... и надеюсь, вам нравится OpenLiberty — это круто!

Гордон

Ответ принят как подходящий

Идем дальше... итак, вышеизложенное - это то, как мы проводим автоматизированное тестирование. но он по-прежнему использует местоположение.

Я вижу, относительно того, что вообще не нужно указывать какое-либо местоположение, вы говорите: «Единственное, что вам нужно сделать, это добавить пару зависимостей Maven в область тестирования, которые используют TomEE (встроенный). Если то же самое будет работать для Open Liberty, это будет здорово».

Итак, подумав, maven поместит кучу классов в путь к классам из-за TomEE зависимости, а затем тестовый прогон найдет подходящий контейнер для запустить тесты дальше.

Я подниму вопрос https://github.com/OpenLiberty/liberty-arquillian/issues/39 чтобы удовлетворить требования, пожалуйста, не стесняйтесь добавлять комментарии и т. д.

Это было бы прекрасно!

sithmein 29.01.2019 21:17

Результат, которого вы, кажется, пытаетесь достичь, - это встроенная среда выполнения для свободы с использованием arquillian. Однако, насколько я вижу, команда openliberty на данный момент предоставляет только адаптер удаленного контейнера и адаптер управляемого контейнера.

Поскольку у нас есть аналогичная потребность, мы хотим запускать автоматические интеграционные тесты, где нам не обязательно иметь сервер Openliberty на месте. Нам удалось обойти это с помощью свобода-maven-плагин.

Тогда процесс сборки/тестирования будет таким:

  1. Запустив mvn verify, свобода-maven-плагин сгенерирует указанную openliberty, против которой мы хотим запустить наши тесты.
                    <plugin>
                        <groupId>net.wasdev.wlp.maven.plugins</groupId>
                        <artifactId>liberty-maven-plugin</artifactId>
                        <version>${version.liberty-maven-plugin}</version> <!-- plugin version -->
                        <configuration>
                            <assemblyArtifact> <!-- Liberty server to run test against -->
                                <groupId>io.openliberty</groupId>
                                <artifactId>openliberty-runtime</artifactId>
                                <version>18.0.0.4</version>
                                <type>zip</type>
                            </assemblyArtifact>
                            <configDirectory>src/liberty/${env}/</configDirectory>
                            <configFile>src/liberty/server.xml</configFile>
                            <serverName>defaultServer</serverName>
                        </configuration>
                        <executions>
                            <execution>
                                <phase>prepare-package</phase>
                                <goals>
                                    <goal>create-server</goal>
                                </goals>
                            </execution>
                        </executions>
                    </plugin>
  1. Поскольку свобода-maven-плагин по умолчанию добавляет сервер Liberty в папку target/
<arquillian xmlns = "http://jboss.org/schema/arquillian">
    <container qualifier = "liberty-managed" default = "true">
        <configuration>
            <property name = "wlpHome">target/liberty/wlp</property>
            <property name = "serverName">defaultServer</property>
        </configuration>
    </container>
</arquillian>

Таким образом, мы можем гарантировать, что работоспособный сервер Liberty по нашему вкусу всегда существует в нашей локальной среде или, например. наш сервер Jenkins CI/CD, по сути, получая тот же эффект, что и встроенный контейнер.

Другие вопросы по теме