Смотри, даже документация на это есть.

Для xfail вместо reason наверно raises имелось ввиду.
Мне не очень понятно зачем тут в целом оба xfail и with raises() - который сам по себе ассерт для всплывающих эксепшенов 😅
https://docs.pytest.org/en/stable/assert.html#assertions-about-expected-exceptions

Хорошо что проблема всплыла - повод подумать где еще такое, и надо ли оно так.

Потому что одно пишется в теле метода, а другое в декораторе.

А оба одновременно зачем в одном тесте нужны? (я себе тоже задал этот вопрос еще час назад, когда заметил) :) В доке пишут (как я увидел и понял), что это одно и то же - просто для разных целей лучше использовать.

Using pytest.raises is likely to be better for cases where you are testing exceptions your own code is deliberately raising, whereas using @pytest.mark.xfail with a check function is probably better for something like documenting unfixed bugs (where the test describes what “should” happen) or bugs in dependencies.

Using pytest.raises is likely to be better for cases where you are testing exceptions your own code is deliberately raising, whereas using @pytest.mark.xfail with a check function is probably better for something like documenting unfixed bugs (where the test describes what “should” happen) or bugs in dependencies.

Потому что когда ты ловишь эксепшн - тест не падает и помечается как пройденный. Декоратором он помечается как xfailed, это другой результат. Зачем так используется в примере - непонятно без контекста.

Using pytest.raises is likely to be better for cases where you are testing exceptions your own code is deliberately raising, whereas using @pytest.mark.xfail with a check function is probably better for something like documenting unfixed bugs (where the test describes what “should” happen) or bugs in dependencies.

не одно и то же

если тест помеченный XFAIL не пофейлится, он будет помечен как XPASS

при этом exit-code пайтеста будет 0, что говорит что все выполнилось успешно

если же проверка в теле with pytest.raises не зарейзит нужный экепшн - тест упадет с DID NOT RAISE и exit-code будет 1

в примере выше написан негативный кейс, который должен пройти только в случае если респонс не 20*. при этом xfail навешан потому что тест вероятнее всего постоянно натыкается на баг (то есть не рейзит ошибку в pytest.raises)

Спасибо!

Вобщем дело было вот в чем:
1. reason это конечно должен быть raises. И это зарешало (стало падать) почему-то только при xdist в несколько потоков, в одном потоке - без проблем все гналось, а после исправления на raises - заработало и в нескольких потоках с xdist.
2. далее все как описал Сникерс - я все это время ковырял откуда «DID NOT RAISE» и разбирался с логикой.

Контекст зарешал, реально. Кому интересно что было далее:

Внутри теста оказался цикл, который я не сразу понял что может содержать свинью, а именно, что один из урлов возвращает 200, а не httperror

Получается вот что: тест не проходит чек на httperror exception, это перехватывает xfail, вуаля - тест типа skipped (xfailed), прогон в целом зеленый. И он такой меченый довольно давно, поэтому его долго не замечали. Ну и репорта на него тоже не оказалось.

Задался вопросом как сделать так, чтобы явно давал ошибку и причину - пришлось рефакторить.
Для себя отметил, что проще было написать более подробные ассерты на статус-коды и разделить title ошибок, чтобы стектрейс был понятен c ходу. А не вот эта вот универсальная магия с 0 информации в консоли о том на каком урле и с каким телом ответа упал тест: сиди дебаж цикл, что там вернулось.

Спасибо @sniiick и @Velikolepniy_05 за терпение и пояснения, кажется это новогоднее чудо, что не послали туда, куда тут обычно шлют. Спасибо всем кто не давал вчера спать и переживал за меня!

Спасибо тебе, что tkinter не прикручивал. (Локальный мем).

1 пункт объясняется тем что при xdist и n>0 (даже 1) пайтест начинает работать в параллельном режиме, где есть контролирующий мастер процесс и подконтрольные ему слейв процессы. с каждого (даже 1) подконтрольного процесса мастер процесс забирает статусы и результат. так как это процессы, а не потоки - все это дело общается через execnet, который умеет передавать только сериализуемые объекты. класс - это сериализуемый объект, но что то где то там не срослось (лень искать в коде пайтеста)

а твоя проблема с дебагом в целом решается логгированием http запросов/ответов и аттачем в тот же аллюр

Спасибо за развернутое объяснение работы xdist, картина стала ещё яснее, искать глубже действительно не стоит.

у меня есть аллюр-отчеты с полным логированием любого запроса-ответа. В эти отчеты лень было идти именно сейчас (не додумался), когда проблема казалось вот вот станет очевидной и решится. Благо, цикл оказался небольшой и даже обычного print хватило, чтобы понять что не так, и на каком элементе, дальше уже полез смотреть что за данные такие в БД лежат, из-за которых 200 код возвращаетсяс, и нашел причину уже в них.

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

With raises это проверка API как ожидаемого контролируемого исключения

Using pytest.raises is likely to be better for cases where you are testing exceptions your own code is deliberately raising, whereas using @pytest.mark.xfail with a check function is probably better for something like documenting unfixed bugs (where the test describes what “should” happen) or bugs in dependencies.

Ну вот тут примерно то же и написано

исключение на ассерт исключения смутило и взрывало мозг какое-то время) по отдельности то я знаю про них)

В итоге xdist таки невиновен? 😂

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

В xdiste нет потоков. Там процессы, так как это питон. И для процессной реализации он работает норм