testomat.io управление авто тестамиТоварищи, подскажите кто как решал примерно такую задачу и можно ли вообще ее решить:
Есть тесты, написанные в #pytest. Данные из базы для тестов выбираются рандомно. Хотелось бы при падении теста отпринтить все переменные из тела теста чтобы подробно знать с каким элементом базы / апи / итд случилась непредвиденная ситуация. Может есть какой-то плагин или вы решали данную задачу сами.
Максимум что можно взять из пайтеста пока что - полные трейсбеки и принт отдающих фикстур перед тестом, а что внутри теста происходит - никому не известно даже при его падении. Заранее спасибо за советы!
Если данные складывать в какое-то специальное поле-объект, то ничто не мешает потом его же вывести при фейле.
Ну это само собой, я думал может чтото есть покрасивее
Про змеиный 
на 100% не скажу, но в жабе 
можно сделать что-то типа:
@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 лайк
Извиняюсь за оффтоп. Но могли бы вы описать свою проблему и специфику подробнее? У меня никогда не было потребности выводить локальные переменные, а если и нужно было, то это делалось явно, а не ключиком, который выводит вообще всё. И второй вопрос - почему в логах теста не хватает информации для их однозначного воспроизведения? Мне кажется, что тут кроется проблема архитектуры и дизайна тестов, а костыль с выводом всей инфы по ключу лишь замылит данную проблему.
Никаких проблем нет, просто хотел ещё больше упростить процесс дебага. Логов хватает на все ситуации
Не бывает проектов без проблем. 
Но если у вас всё хорошо, то я вас поздравляю. Непонятно что хотели упростить, если итак все было ок, а главное для чего…
2 лайка
Тесты иногда бывают с нетривиальной логикой и кроме логов запросов апи и в базу полезно иногда смотреть что происходит с переменными в тесте. Если вы работали с монгой, то вы меня поймете. Там ключ может быть, может не быть, может быть пустой и тд.