<div dir="ltr">Hi James,<br><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 22, 2018 at 9:20 AM James Cooke &lt;<a href="mailto:me@jamescooke.info">me@jamescooke.info</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><u></u>





<div><div>In terms of best practice (what you would like to see if you were reading my test suite), what would you recommend for this test and why? I can see some options...<br></div>
<div><br></div>
<div>* Mark the test as xfail?<br></div>
<div><br></div>
<div>* Adjust the test to pass when stale data is returned?<br></div>
<div><br></div>
<div>* Remove the test from the suite and say the functionality is untested?<br></div></div></blockquote><div><br></div><div>IMHO the correct approach is marking the test as `@pytest.mark.xfail(strict=True, reason=&#39;TODO: fix fake, issue #1234&#39;)`. One of the reasons `@pytest.mark.xfail` exists is to convey the meaning that &quot;this test is failing right now for known reasons, but we want to fix it eventually&quot;, as opposed to `@pytest.mark.skipif` which means &quot;we should skip this test because of &lt;reasons&gt;&quot;, with &quot;reasons&quot; usually being something environment related, like unsupported OS, missing libraries, etc, and that is OK and not something which will eventually be fixed.</div><div><br></div><div>`strict=True` means that, if the fake is fixed (either by you or someone else), then the test suite will *fail*, which will alert you of the fact and then you can remove the `xfail` marker. :)</div><div><br></div><div>Best Regards,</div><div>Bruno.</div></div></div>