<div dir="ltr">Holger,<div><br></div><div style>The only reason I can think of why py.test would perform teardown / finalization differently depending on the nextitem is if class, module, and package level fixtures are being used. If only method level fixtures are used, then they should always get created and always get torn down for each test case. Is that not how it works?</div>
<div style><br></div><div style>We can't re-run just the 'call' phase because the failure of the previous 'call' phase may have left behind a partial situation (see automated testing before we had setup and teardown and fixtures).</div>
<div style><br></div><div style>-Leah</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 23, 2013 at 12:16 AM, holger krekel <span dir="ltr"><<a href="mailto:holger@merlinux.eu" target="_blank">holger@merlinux.eu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey Leah,<br>
<div class="im"><br>
On Mon, Apr 22, 2013 at 15:08 -0700, Leah Klearman wrote:<br>
> Hey Holger,<br>
><br>
> Thank you for the timely patch. I haven't seen Bob online today, but<br>
> hopefully he'll be able to test it very soon.<br>
><br>
> A word of warning: your calling of runtestprotocol() is not quite right<br>
> > and might lead to problems.  "nextitem" should really be the item that<br>
> > is going to be run next.  So if you re-run three times the first two<br>
> > invocations should have nextitem=item.<br>
><br>
><br>
> I agree that that would be ideal, but it only re-runs the test if it fails,<br>
> so I<br>
> would have to know the future in order to know what value to send nextitem=.<br>
> Since hopefully most tests pass the first try, sending nextitem instead of<br>
> item seems to be the better answer.<br>
<br>
</div>FYI pytest perform teardown/finalization according to nextitem:  if your<br>
next item uses different fixtures, the "item" ones may be torn down<br>
(it also depends on the caching scope of the fixtures).<br>
<br>
Do you generally want to re-run the setup or could you also settle<br>
on just re-running the "call" phase of a test?  The latter one would<br>
be easier and probably not disrupt fixture mechanics.<br>
<br>
best,<br>
holger<br>
<div class="HOEnZb"><div class="h5"><br>
> Thanks!<br>
> -Leah<br>
><br>
><br>
> On Mon, Apr 22, 2013 at 1:27 AM, holger krekel <<a href="mailto:holger@merlinux.eu">holger@merlinux.eu</a>> wrote:<br>
><br>
> > Hi Leah, Bob,<br>
> ><br>
> > On Fri, Apr 19, 2013 at 20:55 -0700, Leah Klearman wrote:<br>
> > > Hi Holger and other py.test mavens,<br>
> > ><br>
> > > Bob has reported a problem with my py.test plugin pytest-rerunfailures<br>
> > [1]<br>
> > > not re-running the setup before rerunning the test.<br>
> > ><br>
> > > Looking at my code, it has pytest_runtest_protocol() [2] looping<br>
> > > on _pytest.runner.runtestprotocol() [3], which in turn runs the setup,<br>
> > the<br>
> > > test, and the teardown.<br>
> > ><br>
> > > [1] <a href="https://github.com/klrmn/pytest-rerunfailures" target="_blank">https://github.com/klrmn/pytest-rerunfailures</a><br>
> > > [2]<br>
> > ><br>
> > <a href="https://github.com/klrmn/pytest-rerunfailures/blob/master/rerunfailures/plugin.py#L46" target="_blank">https://github.com/klrmn/pytest-rerunfailures/blob/master/rerunfailures/plugin.py#L46</a><br>
> > > [3]<br>
> > ><br>
> > <a href="https://bitbucket.org/hpk42/pytest/src/fdc28ac2029f1c0be1dac4991c2f1b014c39a03f/_pytest/runner.py?at=default#cl-65" target="_blank">https://bitbucket.org/hpk42/pytest/src/fdc28ac2029f1c0be1dac4991c2f1b014c39a03f/_pytest/runner.py?at=default#cl-65</a><br>

> > ><br>
> > > I haven't taken the hours needed to get my head fully into py.test plugin<br>
> > > development mode, but I'm not sure I can implement a fix at my layer.<br>
> > ><br>
> > ><br>
> > > I'm hoping someone here will have some insight.<br>
> ><br>
> > It's a bit intricate.  A function item keeps around some fixture state<br>
> > and was so far not intended to be run multiple times.  I went ahead and<br>
> > tried to improve the behaviour to better allow re-running.   Please try<br>
> > with<br>
> ><br>
> >     pip install -i <a href="http://pypi.testrun.org" target="_blank">http://pypi.testrun.org</a> -U pytest<br>
> ><br>
> > which should give you pytest-2.3.5.dev16 at least.  This is bound to be<br>
> > released soon so quick feedback is welcome.  If you still have problems<br>
> > please try to send a minimal test file which shows undesired behaviour.<br>
> ><br>
> > A word of warning: your calling of runtestprotocol() is not quite right<br>
> > and might lead to problems.  "nextitem" should really be the item that<br>
> > is going to be run next.  So if you re-run three times the first two<br>
> > invocations should have nextitem=item.<br>
> ><br>
> > best,<br>
> > holger<br>
> ><br>
> ><br>
> > > Thanks,<br>
> > > -Leah<br>
> > ><br>
> > ><br>
> > > On Sun, Apr 14, 2013 at 6:29 PM, Bob Silverberg <<br>
> > <a href="mailto:notifications@github.com">notifications@github.com</a>>wrote:<br>
> > ><br>
> > > > I just verified this behaviour myself with a simple test [1]. I see it<br>
> > > > with both funcargs and fixtures, but I'm not sure if it has to do with<br>
> > the<br>
> > > > plugin, or the way py.test works. It does inject the value into the<br>
> > test<br>
> > > > method, but it doesn't rerun the fixture, so it seems like it is<br>
> > caching<br>
> > > > the first run of the fixture and using that on subsequent runs.<br>
> > > ><br>
> > > > I'm not sure if this is something that the plugin can have any effect<br>
> > on,<br>
> > > > or if it's just the way fixtures work. It is specified for this fixture<br>
> > > > that it is scope='function', and perhaps py.test makes that happen by<br>
> > > > checking the function name, which is, of course, the same for each<br>
> > run. I<br>
> > > > did try removing the scope argument from the fixture but that had no<br>
> > > > effect.<br>
> > > ><br>
> > > > Do you have any thoughts about this, @klrmn <<a href="https://github.com/klrmn" target="_blank">https://github.com/klrmn</a><br>
> > >?<br>
> > > ><br>
> > > > [1] <a href="https://gist.github.com/bobsilverberg/5385035" target="_blank">https://gist.github.com/bobsilverberg/5385035</a><br>
> > > ><br>
> > > > —<br>
> > > > Reply to this email directly or view it on GitHub<<br>
> > <a href="https://github.com/klrmn/pytest-rerunfailures/issues/10#issuecomment-16363644" target="_blank">https://github.com/klrmn/pytest-rerunfailures/issues/10#issuecomment-16363644</a><br>
> > ><br>
> > > > .<br>
> > > ><br>
> ><br>
> > > _______________________________________________<br>
> > > Pytest-dev mailing list<br>
> > > <a href="mailto:Pytest-dev@python.org">Pytest-dev@python.org</a><br>
> > > <a href="http://mail.python.org/mailman/listinfo/pytest-dev" target="_blank">http://mail.python.org/mailman/listinfo/pytest-dev</a><br>
> ><br>
> ><br>
</div></div></blockquote></div><br></div>