Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Allure + TestNG + suite.xml -> Test suite was interrupted, some test cases may be lost

maven
webdriver
java
testng
allure
Теги: #<Tag:0x00007f7b68c91748> #<Tag:0x00007f7b68c914a0> #<Tag:0x00007f7b68c91270> #<Tag:0x00007f7b68c90f78> #<Tag:0x00007f7b68c90c58>

(Дмитрий Гордиенко) #1

Доброго времени суток!
Коллеги, в очередной раз необходима помощь.

Имеется TestNG и сьюта ALL_TESTS.xml.
По результатом выполнения всей сьюты ALL_TESTS.xml, она в алюре помечается как BROKEN с сообщением
Test suite was interrupted, some test cases may be lost, при етом Stacktrace - пуст. Все тесты, которые включены в сьюту - PASSED, скриншоты/файлы присутствуют. С чем такое поведение может быть связано, куда смотреть?

Используется:
allure-testng-adaptor - 1.5.0.RC2
allure-maven-plugin - 2.5

ALL_TESTS.xml:

<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd" >

<suite name="ALL_TESTS" parallel="tests">
    <test name="multi-thread tests" thread-count="2" parallel="classes">
        <classes>
            <class name="test.TestATest"/>
            <class name="test.TestBTest"/>
	    <class name="test.TestCTest"/>
	    <class name="test.TestDTest"/>
        </classes>
    </test>
</suite>


(Vasiliy Rakshin) #2

Используйте версию 1.4.24.RC3.
1.5 версия была экспериментальная.


(Дмитрий Гордиенко) #3

Попробовал. Результат тот же. :frowning:


(Vasiliy Rakshin) #4

Clean делаете перед тестами? Сделайте запуск тестов с пустой папкой таргет.


(Дмитрий Гордиенко) #5

clean использую постоянно. Попробовал руками вычистить таргет - не помогло.


(Vasiliy Rakshin) #6

Попробуйте без параллельности запустить все тесты.


(Дмитрий Гордиенко) #7

Засетил thread-count=“1”… не помогло. Может дело в кастомном листнере…? Я листнер подключал аннотацией над тестовым классом, мож надо еще в сьюте продублировать…?


(Vasiliy Rakshin) #8

Не выключает многопоточность. Уберите вообще параметры потоков и parallel.
Да и листенер пока отключите.
Потом, если пройдёт - подключите листенер, а потом параллельность.


(Дмитрий Гордиенко) #9

Собственно вот и причина - кастомный листенер. Правда пока не пойму чем и как он влияет на аллюр, но без него все отработало. Спасибо :).


(Vasiliy Rakshin) #10

Если не военная тайна - покажите код листенера. http://pastebin.com/


(Дмитрий Гордиенко) #11

Да какая там тайна ))):
http://pastebin.com/KnbZNHUQ

Да еще… Листенер подключен аннотацией к базовому тестовому классу, от которого наследуются все остальные тесты.


(Дмитрий Гордиенко) #12

Частично нашел решение - помогло наследование от листнера из allure-testng-adaptor (AllureTestListener). Проблема в том, что теперь все результаты тестов - дублируются. Предполагаю, из-за того, что ServiceLoader запускает дефалтовый листнер. Есть возможность отключить дефалтовый листнер и использовать только кастомный?

З.Ы следующий вариант не взлетел:

<properties>
  <property>
       <name>usedefaultlisteners</name>
       <value>false</value> <!-- disabling default listeners is optional -->
  </property>
</properties>

(Sergey Korol) #13

Покажите свой ThreadLocalPageContainer. Вообще говоря, смахивает на некорректное использование ресурсов в многопоточной среде. У вас даже сам слушатель противоречив. Если вы действительно помещаете ресурсы в ThreadLocal, то почему инициализация происходит перед запуском каждого теста, а cleanup в глубоком onFinish (который уступает лишь afterSuite в последовательности)?

Помимо этого, из официальной документации TestNG следует, что любой Listener имеет глобальную область видимости.

Note that the @Listeners annotation will apply to your entire suite file, just as if you had specified it in a testng.xml file.

Нет смысла аннотировать его над каждым классом, ибо он будет применен ко всем. Подключайте его только на уровне maven-surefire-plugin. Причем только его. Аллюровского слушателя там не должно быть и в помине с определенной версии.


(Дмитрий Гордиенко) #14

Я старался сделать обычный потокобезопасный контейнер:

package core.utils;

import core.services.SelenideImplPage;

public class ThreadLocalPageContainer {

    private static final ThreadLocal<SelenideImplPage> threadLocalPages = new  ThreadLocal<>();

    public final static SelenideImplPage getThreadLocalPage() {
        return threadLocalPages.get();
    }

    public final static void setThreadLocalPage (SelenideImplPage page) {
        threadLocalPages.set(page);
    }

}

SelenideImplPage - класс-врапер для селенида (с логированием и прочими мелочами).

Не исключено, т.к. ето моя первая попытка сделеать кастомный листенер, буду презнателен за рекомендации.

Перед запуском каждого теста происходит получение имени данного теста, которое используется для логирования (имя логгера). Т.е. даже при паралельном выполнении можно просмотреть лог, грепнув по имени теста, и увидеть процесс выполнения. А в самом конце - “контрольное” закрытие веб драйвера, если по ходу тестов про него забыли.

Да, алюровского листнера там и нет. Спасибо за идею с переносом кастомного листнера в помник. Попробую - отпишусь.


(Sergey Korol) #15

Ну вот вы старались-старались, а надо было вначале почитать, как правильно работать со ThreadLocal. Сам факт того, что вы только добавляете и совсем не чистите свои контейнеры, автоматически указывает на потенциальные утечки памяти и некорректное использование ресурсов. Ввиду того, что TestNG переиспользует потоки, в вашем ThreadLocal наверняка хоронится тонна навсегда потеряных ссылок.

Все равно я пока не пойму вашей архитектурной задумки. Исходя из названия, обертка работает с какой-то пейджой. Но зачем конкретную пейджу помещать в потокобезопасный контейнер, если TestNG уже сам по себе дробит сущности по потокам? Хотя, возможно дело конечно в контексте масштабирования, который привязан к уровню классов. Но опять-таки, не совсем понятно, где и по каким правилам в этой всей цепи происходит инициализация драйвера.


(Дмитрий Гордиенко) #16

Спасибо, учту. Скорее всего после выполнения теста буду “убивать” ссылку в контейнере.[quote=“ArtOfLife, post:15, topic:11529”]
Исходя из названия, обертка работает с какой-то пейджой.
[/quote]
Возможно наличие “page” в имени класса сбивает с толку… По сути ето класс, который содержит в себе все базовые дейсвия (startDriver, clickOn, goTo…).
Сам веб драйвер создается уже в тестовых классах в зависимости от необходимости: один на все тесты (в аннотации @BeforeClass) ну или в каждом тесте новый. Создание происходит посредством методов “пейджи” - сетится поле класса и WebDriverRunner селенида.


(Sergey Korol) #17

Это говорит о неверно спроектированной архитектуре. Тесты ничего не должны знать о драйвере. Ровно, как и страницы. Все проблемы как правило тянутся из-за жуткого микса доменной логики с низкоуровневой составляющей. Все, что касается драйвера, должно быть вынесено в отдельный модуль.

Базовые действия у вас тоже намиксованы. Логика создания драйвера и управления поведением должны быть разнесены. Страницы не должны заниматься поднятием браузера. Это не их задача.


(Дмитрий Гордиенко) #18

Все ето верно, и архитектуру однозначно нужно дорабатывать. Печально что пока проблемка с репортами остается… :frowning: