Repository navigation
ExceptionGroup ergonomics in pytest.param(..., marks=xfail(raises=...)) #12504
Description
Activity
I might be seeing nails everywhere, but I would do
return pytest.param( ..., marks=pytest.mark.xfail(raises=RaisesGroup(IndexError), strict=True), )
and afaict the only code doing the matching is
pytest/src/_pytest/skipping.py
Lines 280 to 281 in d9a2fd0
where it would be straightforward to addif isinstance(raises, RaisesGroup) and not raises.matches(call.excinfo.value): rep.outcome = "failed" elif raises is not None [...] ...
This of course depends on #11671 (or a version that fully implements trio.RaisesGroup functionality).
Reacted by Zac Hatfield-DoddsActually, I don't see why this is about
pytest.paramat all. Ifpytest.mark.xfail(raises=...)got support forRaisesGroup(or equivalent) it should Just Work ™️@pytest.mark.xfail(raises=RaisesGroup(ValueError)) def test_foo(): raise ExceptionGroup("foo", [ValueError])
#11671 has fallen behind the trio implementation, and is stalled by people wanting to have opinions on the interface design, otherwise I'd resolve this issue in it right away.
Reacted by Zac Hatfield-Dodds- added a commit that references this issue
on Jan 5, 2026
Suppose you have a parameterized test, some params of which are expected to raise (e.g.)
IndexError:If your test is async though, you'll actually raise an
ExceptionGroup(..., [IndexError])(maybe with even more nesting), so the tests will still fail. Can we make this more ergonomic? What would a parametrize-awareRaisesGroup-like thing look like?See also #11538 and #11671.