Allure testNg Как сделать имя класса сьютом для содержащихся в нём тест-методов?

инфраструктура allure
,
#1

Проект webdriver + junit + maven + allure. На этой неделе из-за ограничений junit перевёл на testNg.
Структурно пакет с тестами состоит из классов с тестовыми методами в них.
Классы объединяют незначительно различающиеся тесты (методы) по смыслу для облегчения ориентирования в проекте; или же являются аналогами тест-кейсов, в том случае, если после выполнения шагов имеются множественные взаимонезависимые неодносложные проверки (отдельные методы).

С Junit методы в Allure отчёте группировались по классам. В testNg уровень классов игнорируется и всё сливается в одну кучу. Вопрос: как сделать, чтобы методы группировались по классам, как с Junit, или, если всё печально, как можно структурно переиначить, чтобы это было нормально поддерживаемо allure?
Запуск производится через maven

#2

как вариант, для каждого метода в Тестовом классе пропишите @step и вызовите все по порядку в одном методе @Test и в аллуре при нажатии увидите шаги вашего тест кейса. Чтобы имя кейса отображалось в аллуре, нужно создавать testng.xml и там прописывать смотри

Либо просто для каждого класса(тест кейса) создаете свой testng_testname.xml, в котором задаете имя сьюта и тогда отчет будет корректно формироваться, не забудьте в maven-surefire-plugin в configuration> добавить

<code>
<suiteXmlFiles>
                        <suiteXmlFile>${basedir}/src/main/resources/all-tests.xml</suiteXmlFile>
 </suiteXmlFiles>
</code>

и в главном файле всех тестов указать xml всех классов

#3

Тут есть пару вопросов

  1. Можно просто в testng.xml файле группировать. Там можно хоть класс отдельно, хоть пакетами группировать.

  2. Какое именно ограничение JUnit вас остановило?

Плюс - может быть @ArtOfLife даст какой-то совет - он в testNg “собаку съел” + с недавних пор активнейшим образом аллюром увлекся :smile:

#4

Спасибо! Но, занести всё шагами не могу, т.к. это всё же независимые проверки, которые очень желательно выполнять отдельно друг от друга, в том числе из-за false negatives на отдельных шагах и сбора тестовых артефактов, как например, js ошибок по ходу выполнения. Можно было бы применить soft assertions, но, к сожалению, тесты почти всегда падают не на failures, а на errors какой-то смежной функциональности, где ошибки не ожидаются, да и предвосхитить их все - невозможно.

Насчёт вашего второго варианта думал, но это же жесть)) Если и создавать дурацкий xml-ник на каждый файл руками и прописывать названия suite, test, class(аж три параметра). То надо ещё и в ручную прописывать весь скоп тестов в мастер файле. В результате обязательно что-то будет теряться и путаться. А если придётся рефакторить имена или менять пакеты…

#5

в ссылке, что я привел, ответ разработчика allure" получить нормальное имя сьюта никак без xml", а вам именно это и нужно в отчете, как я понял, один класс - один кейс (сьют)

#6
  1. Ну вот в том то и дело, что, как ни группируй, а если выбрать для исполнения Class1, Class2

Class1

  • method1
  • method 2

Class2

  • method 1
  • method 2

то, в результате в репорте будет
НекийSuite

  • method 1
  • method 2
  • method 1
  • method 2
  1. Остановили static @Before, отсутствие упорядочивания выполнения тестов на уровне класса (про лучшие практики знаю))
Allure - подборка типичных проблем возникающих в процессе использования и их решения
#7

Да, это я сознаю. Вероятно, я не смог достаточно точно выразить свою мысль. Смотрите, мавеном я запускаю .xml, в котором указаны имена suite и test, например

В отчёте я получаю Suite:Name в котором лежат все методы всех классов этого пакета.
Я же хочу получить мою проектную вложенность.
После Suite:Name должны идти классы, заныривая в которые уже отображаются тест-методы =)
Это невозможно и я должен делать мои классы аллюровыми сьюитами?

#8

Попробуйте в вашем примере указывать имена тестов в одном файле под одним сьютом

test name = “first test”
package name = “com…first test”

test name =“second name”

package name = “com…second test”

#9

static Before - это да. Странно, почему они вообще его сделали таким. Но в целом это не должно быть проблемой.
Второе - вообще хорошо, если ваши тесты - независимы. Тогда и не нужно упорядочивание.

#10

Попробуйте, аннотировать класс, через @Features. Тогда по идее на вкладе Behavior вы получите вашу вложенность.

2 лайка
#11

При текущей реализации testng-adaptor - никак не решите проблему. У них сейчас не полностью соблюдена структура самого testng. Test suite = suite (tag) + test (tag) + parameters. Все остальное - это тестовые методы. Отсюда и ноги растут у этой проблемы.

Так что тут у вас 4 варианта:

  • Переписать testng-adaptor под ваши нужды.
  • Дописать отсутствующий функционал.
  • Наплодить миллион xml, адаптируясь к текущей структуре.
  • Изменить саму структуру.

Update: хотя, наверное самое простое - подогнать тесты таким образом, чтобы они были объединены в группы по test тегу. Т.е. в пределах 1 xml объявите N test групп ,в которых будут индивидуальные классы. Но если классов много, то это будет ничем не лучше варианта с кучей suite. Т.е. структурно в проекте ничего не изменится. Вам нужно будет лишь правильно сформировать xml.

1 лайк
#12

Сделал как вы предложили. Наиболее простой вариант вышел. И запускать буду без testng.xml
Появится время, - попробую допилить testng-adaptor

#13

Так же делаю!
Но не могу понять, как отображать в Аллюр отчете имена тестовых функций русскими буквами?

Делаю так:

@Features("Такой-то функционал")
public class TestCase {

       @Test
       @Title("конкретный тест")
       public void testFunc(){
            ...
       }
}

В Аллюре вижу тестовую функцию как testFunc, а предполагал, что увижу как указано в @Titile =)

Подскажите плиз, как сделать имена функций на русском в Аллюр отчете?

#14

1С бухгалтерию автоматизируете ? ))) Мое имхо, кириллицу надо избегать везде где только возможно, проблем от нее больше чем полезностей. Даже при банальном переходе из Eclipse в IDEA, строковые константы в кириллице могут поплыть, это можно не заметить и закоммитить, а потом удивляться, почему тесты падают. Актуально для распределенных команд, у которых свои предпочтения в IDE и пр.

1 лайк
#15

тут где я, так исторически сложилось, что любят смотреть аллюр отчетики менеджеры и ручные тестировщики и хотят русских букав

#16

Нашел!

@Test
@Description("Описание")
public void testFunc(){

}

@Description - аллюревская аннотация

Правда это не обзывает тестовую функцию в отчете (столбец Titile) по-русски, но дает возможность описать кириллицей функцию при нажатии на нее и открытии окна с подробностями