Вывести все переменные из тела теста при его фейле

Товарищи, подскажите кто как решал примерно такую задачу и можно ли вообще ее решить:
Есть тесты, написанные в #pytest. Данные из базы для тестов выбираются рандомно. Хотелось бы при падении теста отпринтить все переменные из тела теста чтобы подробно знать с каким элементом базы / апи / итд случилась непредвиденная ситуация. Может есть какой-то плагин или вы решали данную задачу сами.
Максимум что можно взять из пайтеста пока что - полные трейсбеки и принт отдающих фикстур перед тестом, а что внутри теста происходит - никому не известно даже при его падении. Заранее спасибо за советы!

Если данные складывать в какое-то специальное поле-объект, то ничто не мешает потом его же вывести при фейле.

Ну это само собой, я думал может чтото есть покрасивее

Про змеиный :snake: на 100% не скажу, но в жабе :frog: можно сделать что-то типа:
@After
public void tearDown(){
log.info(createJson(this));
}
Выведет в формате json’а все поля объекта тестового класса, в том числе и родительские. За исключением статики.

если правильно понял, то ключ -l делает именно это, сам пользуюсь, но уже реже - читаемые сообщения в ассертах + аттачменты запросов (API, база и т.д.) - намного удобнее

https://docs.pytest.org/en/latest/usage.html#modifying-python-traceback-printing

pytest --showlocals # show local variables in tracebacks
pytest -l           # show local variables (shortcut)
3 лайка

да и вообще в pytest много ключиков на все случаи жизни, если чего-то нет, то скорее всего есть плагин =)

Понравилось использование ключа --showlocals. Проверил на простом тесте, вроде то что я хотел:

FAILED
____________________________________ test_1 ____________________________________
    def test_1():
        a = 3
        b = 7
        c = a + b
        d = c - a - b
>       assert False
E       assert False
a          = 3
b          = 7
c          = 10
d          = 0
tests_api/test_1.py:6: AssertionError

Сейчас попробую на реальных тестах.
Спасибо!

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

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

Нет, самый весомый аргумент против данного метода - когда из апи либо из базы приходит хороший такой массив из ~500 элементов и у каждого элемента по 20 ключей. Тест падает из-за чего-либо и все это полотно начинает принтиться. А выбрать что принтить а что нет - не думаю что это реализовано. Хотя я и не искал пока

А, понял, ну так я писал - выбираешь ровно, то, что надо и в сообщении в ассерт, и этот ключ убираешь - это самый норм подход)

1 лайк

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

Никаких проблем нет, просто хотел ещё больше упростить процесс дебага. Логов хватает на все ситуации

Не бывает проектов без проблем. :sunglasses:
Но если у вас всё хорошо, то я вас поздравляю. Непонятно что хотели упростить, если итак все было ок, а главное для чего…

2 лайка

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