Fixed an issue with running the same test multiple times sequentially

[yuvalino]

When pytest_runtest_protocol is called with item==nextitem multiple times, with a test that accepts some fixtures -> the second call forward raises an error.

This is caused in WorkerInteractor when the same test appears twice in a row in the queue.

So if this specific case occurs, ensure nextitem is called with None instead.

[bluetech]

When pytest_runtest_protocol is called with item==nextitem multiple times

I am assuming you are using a plugin which does this. Which plugin is it?

[yuvalino]

pytest-xstress

This is a custom xdist scheduler I'm working on.

I've wrote a workaround for now:
yuvalino/pytest-xstress@e74be4d#diff-174fb39bb2968a8f78ff7ba54c6600843d794c9683efe83987b4291b6ab4db2c

[nicoddemus]

Thanks @yuvalino however we also will need a regression test for your change for this to be considered for merging.

[amezin]

the second call forward raises an error.

But what's the error exactly? Is it raised by xdist or pytest core?

nextitem=None will tear down all fixtures (including session scope), if I'm not mistaken. And some code (especially in other plugins) likely assumes nextitem=None means "end of session".

[yuvalino]

@amezin exception is raised by the pytest core, the fixtures are not passed to the "nextitem", so the invocation of the second runtest_protocol fails.

@nicoddemus please explain better what do you mean? as far as I'm aware, no scenario where the same (which is not the case in pytest-repeat) item is executed twice in a row over xdist so there's no regression there, nor in any other use-case of xdist.

I've finished my work by developing multiple plugins (pytest-publish, pytest-xstress) and have come with a final, new vision for tests:

https://github.com/yuvalino/pytest-infinity

Please help me get this fix out to mainline xdist :)

[amezin]

@amezin exception is raised by the pytest core, the fixtures are not passed to the "nextitem", so the invocation of the second runtest_protocol fails.

Shouldn't the fix be implemented in pytest core then?

Also, could you show the exact error - message, stack trace?