[Resolved] Настройка Maven под загрузку различных наборов suite.xml

hroft356 · 02.Ноябрь.2014 16:46:22

Всем привет:) Встала необходимость научить мой фреймворк запускать несколько различных suite с набором тестов и управлять этим набором при помощи профилей. Использую связку Maven+TestNg.
Сперва я создал несколько property с путями к моим suite:

<properties>
     <suiteWalletXml>src/.../all_wallet_tests.xml</suiteWalletXml>
     <suiteCheckoutXml>src/.../all_wallet_external_tests.xml</suiteCheckoutXml>
 </properties

Дальше я связал эти два сьюита путем:

<defaultSuiteFile>${suiteWalletXml},${suiteCheckoutXml}</defaultSuiteFile>

И наконец объявил общую property которую будет подхватывать maven:

<suiteFile>${defaultSuiteFile}</suiteFile>

Соответственно в настройках maven-surefire-plugin в конфиге указываю это property:

 <plugin>
                    <groupId>org.apache.maven.plugins</groupId>
                    <artifactId>maven-surefire-plugin</artifactId>
                    <version>2.17</version>
                    <configuration>
                        <suiteXmlFiles>
                            <suiteXmlFile>${suiteFile}</suiteXmlFile>
                        </suiteXmlFiles>
...

При запуске тестов, Maven ругается на src/…/all_wallet_external_tests.xml из property ${suiteCheckoutXml}, обзывая его не валидным. Если property определить как:

<defaultSuiteFile>${suiteWalletXml}</defaultSuiteFile>

или же

<defaultSuiteFile>${suiteCheckoutXml}</defaultSuiteFile>

Тесты запустятся, показывая тем самым, что сами *.xml валидны, а ошибка именно в их групировки.
Стек трейс ошибки:

Failed to execute goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test (default-test) on project autotests: Execution default-test of goal org.apache.maven.plugins:maven-surefire-plugin:2.17:test failed: There was an error in the forked process
[ERROR] org.apache.maven.surefire.testset.TestSetFailedException: Suite file src\main\resources\suites\all_wallet_external_tests.xml is not a valid file
[ERROR] at org.apache.maven.surefire.testng.TestNGXmlTestSuite.locateTestSets(TestNGXmlTestSuite.java:116)
[ERROR] at org.apache.maven.surefire.testng.TestNGProvider.invoke(TestNGProvider.java:84)

Кто нибудь сталкивался с подобной проблемой? Возможно есть другой путь решения моей задачи?

ArtOfLife · 02.Ноябрь.2014 20:31:12

Основной xml, который комбинирует в себе sub-xml с тестами.

<?xml version="1.0" encoding="UTF-8"?>
        <!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >
<suite name="ParentSuite">
    <suite-files>
            <suite-file path="CH-suite.xml"/>
            <suite-file path="FF-suite.xml"/>
            <suite-file path="IE-suite.xml"/>
    </suite-files>
</suite>

Профиль в pom.xml, который проверяет наличие переменной окружения SUITES. Ее можно задать, к примеру в качестве Jenkins job parameter для указания набора сьютов, который мы хотим заэкзекьютить. В случае отсутствия переменной окружения, будет использовано дефолтное имя - global.suites.

        <profile>
            <id>if-suite-exists</id>
            <activation>
                <property>
                    <name>!env.SUITES</name>
                </property>
            </activation>
            <properties>
                <suites>global.suites</suites>
            </properties>
        </profile>

Далее в maven-surefire-plugin секции задаем имя сьюта для запуска, путем чтения suites property. Там будет либо значение из переменной окружения, либо дефолтный сьют нейм:

<suiteXmlFiles>
    <suiteXmlFile>src/test/resources/suites/${suites}.xml</suiteXmlFile>
</suiteXmlFiles>

Естественно, сьют с указанным именем должен существовать в указанной директории, иначе получите эксепшен.

П.С. Для “спасибо” есть спец кнопка, если еще не читали FAQ.

Funker · 02.Ноябрь.2014 22:39:38

есть еще один вариан через mavn profile пример файла можно посмотреть здесь pom.xml
может не самый удачный вариант но тоже имеет право на существование.

hroft356 · 03.Ноябрь.2014 06:11:41

В приложенном pom.xml через профайл подключается только 1 testng.suite. А у меня стоит задача подключать сразу по 2-3 и т.д. suite

hroft356 · 03.Ноябрь.2014 06:20:44

Спасибо за развернутый ответ, но я в свое время ушел от этого способа, т.к. testNg не умеет запускать параллельно suite-file. Поэтому каждый suite.xml у меня имеет стандартный вид:

<suite name="Wallet" verbose = "10" parallel="tests" thread-count="3">
    <test name = "Платежная форма">
        <classes>
            <class name = "wallet.payment.form.PaymentFormSeleniumTest" />
        </classes>
    </test>
</suite>

В силу этого мне и нужно научить maven собирать по несколько типовым sute в сборку

Я пробовал банальный метод, который работает. Я просто в конфиг передал все sute.xml, которые мне нужны:

<configuration>
                    <suiteXmlFiles>
                        <suiteXmlFile>.../suite1.xml</suiteXmlFile>
                        <suiteXmlFile>.../suite2.xml</suiteXmlFile>
                    </suiteXmlFiles>

Все работает, но при таком подходе я не смогу управлять сюьитами, через профайлы, например. Бывает ситуация, когда нужно прогнать просто 1 тест для дебага, чтобы убедиться в работоспособности удаленного хаба, к примеру. Тогда задача бы свелась просто в выборе нужного профайла, который бы определил кол-во suite.xml для этого

ArtOfLife · 03.Ноябрь.2014 07:41:41

А зачем запускать параллельно именно сьюты, если вы знаете, что у testng с этим проблемы? В случае, описанном мною выше, осуществляется последовательное выполнение сьютов, но параллельное выполнение тестов внутри каждого из них. К примеру:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Chrome test suite" parallel="tests" thread-count="2">
    <parameter name="hubURL" value="http://x.x.x.x:4444/wd/hub"/>
    <parameter name="proxyIP" value="x.x.x.x"/>
    <test name="Chrome 28 - Win7">
        <parameter name="browser" value="chrome"/>
        <parameter name="version" value="28"/>
        <parameter name="browserID" value="ch28_1"/>
        <parameter name="platform" value="WINDOWS"/>
        <parameter name="nodeIP" value="x.x.x.x"/>
        <classes>
            <class name="com.company.testcases.authorization.AuthorizationTests">
                <methods>
                    <include name="correctLogin"/>
                    <include name="incorrectLogin"/>
                    <include name="correctLogout"/>
                </methods>
            </class>
        </classes>
    </test>

    <test name="Chrome 28 - Win8">
        <parameter name="browser" value="chrome"/>
        <parameter name="version" value="28"/>
        <parameter name="browserID" value="ch28_2"/>
        <parameter name="platform" value="WINDOWS"/>
        <parameter name="nodeIP" value="x.x.x.x"/>
        <classes>
            <class name="com.company.testcases.authorization.AuthorizationTests">
                <methods>
                    <include name="correctLogin"/>
                    <include name="incorrectLogin"/>
                    <include name="correctLogout"/>
                </methods>
            </class>
    </test>
</suite>

Я вам привел пример аналогичной ситуации, но несколько под другим углом. Проблема в том, что в случае с профайлами вам каждый раз придется лезть в pom.xml, чтобы добавлять / удалять / редактировать нужные для запуска сьюты (хотя, по сути в моем примере тоже используется профайл, но он 1 и постоянный). В случае с xml, вы вольны выбирать одно из следующих решений:

засетить имя нужного сьюта через указанную выше переменную окружения;
модифицировать parent suite, чтобы тот указывал на нужный вам
саб-сьют (или набор);
напрямую задать нужный вам сьют через pom.

Причем в предложенной мной конфигурации вы абсолютно никак не зависимы от pom’а, кол-ва сьютов внутри парента или структуры самих сьютов в целом. Maven-surefire-plugin просто выполнит указанный сьют без лишних вопросов.

П.С. Нужно запустить 1 тест? У меня для этого есть дебаг-сьют, который я модифицирую. При этом, мне не нужно лезть в pom. Раз уж testng предоставляет способ управления запускаемыми тестами через xml, то почему им не пользоваться? Зачем лезть в конфигурационный файл всего проекта, который вообще не должен быть привязан к конкретным тестам?

hroft356 · 03.Ноябрь.2014 13:38:26

Еще раз более внимательно посмотрел предложенное вами решение и нашел его очень эффективным!
Действительно, подобный путь приводит к отделению конфигурации всего проекта и средств запуска тестов TestNg.
Так же был приятно удивлен, обнаружив что после запуска определенного suite.xml из набора, тесты внутри него бегали параллельно.
Спасибо за помощь!)