Brian Okken comments

Results 101 comments of


                                            Brian Okken

add `run` parameter to `pytest.xfail()`

Another alternate workaround is to put the original workaround in a fixture: ```python @pytest.fixture() def xfail(request): def _xfail(reason=''): request.node.add_marker(pytest.mark.xfail(reason=reason)) return _xfail def test_xfail_pass(xfail): xfail(reason='should xpass') assert 1 == 1 def...

add `run` parameter to `pytest.xfail()`

After looking at the code I was worried about the need for a `request` object to be passed in. It's not a real clean interface then, but would work. Is...

add `run` parameter to `pytest.xfail()`

@RonnyPfannschmidt I'm glad you have an idea about this. I don't know understand really how contextvar wold be applied.

add `run` parameter to `pytest.xfail()`

Until we get this sorted out, I've added a plugin for the workaround, [pytest-runtime-xfail](https://github.com/okken/pytest-runtime-xfail). The name's a bit long, but it works-ish. I'd rather have it built into the `pytest.xfail()`.

pytest_check is the only pytest plugin that uses an underscore in its name

decent point.

pytest_check is the only pytest plugin that uses an underscore in its name

fixed with version 1.0.6

Is early error checking possible?

Failing early isn't something I considered before, but not a bad idea. Maybe something like an `assert_no_failures()` function. Would that work for your use cases?

Support --tb=no in message trackback style

Thanks for this, I'll check it out.

Define a GH Action for automated release publishing

thanks for the info

Using `--showlocals` does not print variables

I agree that it would be nice if showlocals worked with this plugin. If you'd like to work on a PR for this, that'd be cool.