Отображение упавших шагов в отчете Allure

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

Добрый день!
Стал на днях причесывать тесты по одному моему старому проекту. И вот при анализе прогона тестов в отчете Allure подумалось мне, что очень неудобно определять причины падений. Суть в чём: у меня тесты состоят из шагов, есть жесткие ассерты и магкие (сделаны через ErrorCollector). Если тест падает по жесткому ассерту, то там всё более-менее понятно, что и где упало. А вот если тест дошел до конца, но по какой-то причине отвалилось 3, 4 или N проверок, то мне тогда нужно заходить внутрь каждого шага и смотреть, что там лежит в аттаче (у меня сделан аттач с текстом вида: ошибка при проверке поля такого-то: ожидали “х”, получили “у”). Но по внешним признакам такой шаг в отчете не виден, они все зеленые в ответе. Тут еще такая особенность, что ошибка в ErrorCollector’е не видна просто так.

Я бегло погуглил по теме, но ничего внятного не нашел, только в паре мест упоминались в вопросах:
https://stackoverflow.com/questions/29021244/allure-framework-how-to-fail-only-one-step-in-the-test-method

https://github.com/allure-framework/allure2/issues/456

И даже на нашем форуме есть тема схожая, но немного о другом. Кстати, на вопрос тот так никто и не ответил…
https://automated-testing.info/t/allure-cucumber-jvm-prikreplenie-attachmentov-k-upavshemu-shagu-v-otchyote-allure-v-zavisimosti-ot-tega-cucumber-feature/9976

Причём тут вопрос даже не в том, чтобы я смог быстро понять по отчету что-то, а в том, чтобы и другим людям приносил максимальную пользу. Сейчас же в отчете множество зеленых Step’ов внутри которых скрывается описание ошибки и чтобы понять что к чему - нужно все шаги развернуть и проверить вложения.

Может в 3-й такое есть? Артем вроде бы недавно про неё делал доклад даже:
Артем Ерошенко — Вы всё еще пилите свой отчет? Тогда мы идем к вам!
Я увидел в докладе про постройку своего дерева тестов, но не понимаю как в это дерево красить шаги. Т.е. теоретически в момент чека и добавления ошибки в errorCollector, я могу узнать из какого шага возникло данное исключение, но что мне дальше делать с этой информацией - пока не знаю.

У кого-то было что-то похожее? Использовать один тест - одну проверку или валить тест при первом же ассерте - не вариант. Использовал когда-то свой самопальный html-отчет в виде таблички, так там каждую упавшую проверку было видно сразу и понятно было в каком месте и что искать.

#2

Во второй это тоже есть. Просто надо немного переписать его под себя.

#3

Могу только гипотетически подсказать.
Все ваши ошибки собирать, если они есть. И прикреплять в каком-нибудь @афтерТест ошибкиМягкихПроверок(), если не пусто. Всё собрано будет в одном месте, если есть ошибки - @афтертест зелёный, а можно сделать и выброс какой-нить общей ошибки - тогда этот шаг будет красный.

#4

Ну, в принципе у меня так сейчас и работает. Но это все равно не очень удобное решение. Т.е. тест с точки зрения тестировщика это непрерывный процесс без ветвлений от точки А до точки Б с шагами. У каждого шага есть свой статус (как в ALM системах): пройден успешно; пройден, но есть ошибка; не пройден, дальнейшее движение заблокировано. Если ошибка критичная и не можем продолжить тест, то падаем «жестко», если же среди 20 полей в базе у двух-трех что-то отвалилось (изменилось поведение, некорректно описали модель в тесте), то валить тест сразу не имеет смысла, а наоборот лучше собрать все такие ошибки за один прогон. И если я буду добавлять шаг «проверка мягких ассертов», то это не корретно с точки зрения описания теста (и про него еще нужно всегда помнить и держать в голове), т.к. этот шаг не имеет к тесту отношения, а только к тому как мы у себя в коде его реализовали. Я считаю, что тест должен быть максимально абстрогирован от этого и должен быть в бдд-стиле, даже если бдд не используете. Т.е. по шагам должно быть понятно что делается и зачем, а также где и какие проблемы возникали.

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

#5

Подкрашивание шагов красным есть и во втором аллюре, вы чего :slight_smile:
Всё зависит от реализации.
Вам никто не мешает написать свою реализацию, чтобы можно было делать софтассерты с красными шагами.

1 лайк
#6

Спасибо! Оказывается, что всё украдено до нас. Решение через lifecycle было ещё в 1-й версии:
https://github.com/allure-framework/allure1/issues/967

1 лайк
#7

А каким образом можно подкрасить? У самого Allur есть такая возможность и надо просто прописать команду?
Я использую python.

#8

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

Allure.LIFECYCLE.fire((StepEvent) context -> context.setStatus(Status.FAILED));

Вообще, судя по всему там можно с нуля весь отчёт нарисовать без аннотаций над методами, создавать новые шаги и подшаги и т.д. Кроме этого есть другие статусы, которые можно пробросить: BROKEN, PASSED, SKIPPED, CANCELLED и PENDING.

Судя по всему вот тут есть ответ для Python’а:
https://github.com/allure-framework/allure-pytest/blob/master/demo/test_steps.py

И вот тут отличное видео про lifecycle Allure от Артема:
Allure 2 Lifecycle: free integration with tools - Artem Eroshenko

image
image2015×1511 961 KB

2 лайка