+1 for making tear downs consistent and clear for all the scopes Having teardown argument solves it to me On Sep 22, 2014 10:03 PM, "Andreas Pelme" <[email protected]> wrote:
> Hi Holger, > > On 19 sep 2014, at 09:52, holger krekel <[email protected]> wrote: > > I presume that with module and class scope people don't presume that > > a fixture survives until the end of a process so eager teardown is less > > of a problem, there, right? > > > I have not fully grasped how fixture teardown currently happens in pytest. > To explore it, I came up with this example: > > import pytest > > > @pytest.yield_fixture(scope='class') > def fix(): > print 'fixture setup' > yield > print 'fixture teardown' > > > > class TestFoo(): > def test_a(self, fix): > print 'test_a' > > def test_b(self): > print 'test_b' > > def test_c(self, fix): > print 'test_c' > > > It gives me the output (with the latest pytest from PyPI): > > fixture setup > test_a > test_b > test_c > fixture teardown > > I.e. even though test_b does not actively request the fixture, it is > active during the test. > > Is this even considered to be a bug or a feature? :-) This behavior may be > considered a bug since it makes test suites brittle - if the fixture does > not contain a value itself, it can probably be neglected to actually > properly request the fixture, but test_b will still accidentally have “fix” > available. Bugs like this will only show itself when running a subset of > the test suite (and with xdist!). > > I would prefer (I think) if all fixtures where torn down when they are not > requested (in my example, before test_b is run, to ensure test_b is only > run with its own fixtures). > > However, if all teardowns worked like this, the efficiency will be very > bad since there will be a lot of teardowns. I think these fixtures that > should be allowed to stay alive, should be explicitly declared like that, > like the option to pytest.fixture() suggested earlier. > > I think this makes sense regardless of whether the fixture is class, > module or session scoped. Having different semantics depending on the scope > would be confusing. Fixture authors must be aware and decide whether or not > a fixture may accidentally be available to wrong tests. I have a hard time > to see how we can solve this properly without a flag or some kind of > distinction for this. > > I am probably missing a lot of details here, what are your thoughts on > this? > > Cheers, > Andreas > >
_______________________________________________ Pytest-dev mailing list [email protected] https://mail.python.org/mailman/listinfo/pytest-dev
