Bruno Oliveira <nicodde...@gmail.com> writes:
> Hi everyone and Holger,
>
> Looking at the code below:
>
>
> data = {}
> @pytest.fixture(scope='session')def clean_data():
> data.clear()
> @pytest.fixture(autouse=True)def add_data():
> data['value'] = 1
> @pytest.mark.usefixtures('clean_data')def test_foo():
> assert data.get('value')
>
> Should test_foo fail or pass? Keep your answer in mind before
> proceeding. :)
Nice example. To be honest, my first reaction was that this is probably
undefined.
Part of my unhelpful side also thinks this is horrible anyway so why
should we help people write bad code?
> I ask this because *unrelated* fixtures, i.e. which don’t depend on each
> other, are executed in the order they are declared in the test function
> signature, regardless of scope.
That the order is defined *is* surprising to me. And it honestly smells
like an implementation detail.
> I opened up a PR <https://github.com/pytest-dev/pytest/pull/3306> which
> does sort parameters by scope while keeping the relative order of fixtures
> of same scope intact, and the test suite passes without failures so if the
> current behavior is by design there are not tests enforcing it. Using code
> in the PR, then things might also be surprising:
>
> @pytest.fixture(scope='session')def s(): pass
> @pytest.fixture(scope='function')def f(): pass
> def test_foo(f, s):
> pass
>
> s and f are unrelated and execute in (f, s) order in master, but in (s, f)
> order in my branch.
This seems very reasonable to me, but then I never considered the order
of arguments important at all. I don't really mind introducing the
patch you suggest. But the pedant in me would still not want to make
any more guarantees other then the scoping, i.e. if you have
test_foo(f1, f2, s) then the order of f1,f2 should remain undefined
despite that s is going to be called first.
> Would like to hear what people think about this matter, as I think it is an
> important one, specially *Holger* if this is a design decision or just an
> accident of implementation, and if we should change it.
My biggest worry is that this is a slippery slope. E.g. why isn't a
session-scoped fixture initialised right at the start of the session?
Once your mental model has adjusted to this the current behaviour is
pretty natural (and probably why I don't see it as an issue). But I
accept I know probably too much about pytest and do think the PR might
make things more intuitive for people.
Cheers,
Floris
_______________________________________________
pytest-dev mailing list
pytest-dev@python.org
https://mail.python.org/mailman/listinfo/pytest-dev
