<div dir="ltr"><div><div>Hi Brian,</div><div><br></div><div>Here are some of the uses we have for autouse fixtures at work. I'm just throwing them here without much filtering in the hope that it is useful as an example.</div><div><br></div><div>We have some global autouse fixtures which live in plugins/conftest files and are applied to the entire test suite:</div><div><br></div><div>* Set global test suite configuration by using session-scope autouse fixtures that:</div><div><br></div><div> * Disable crash dialogs on Windows;</div><div> * Set environment variable related to testing (for example: "TESTING=1");</div><div><br></div><div>* Autouse function-scoped fixture which uninstall mocks installed from an internal mocking library (for historical reasons only, new code uses ``mock`` or pytest-mock[1] directly);</div><div><br></div><div>Here I would recommend caution on using function-scoped autouse fixtures, as now all tests in the suite will use that fixture implicitly. Caution must be taken also on session-scoped autouse fixtures specially related to dependencies: importing a large library like Qt on such a fixture will impact your day-to-day when you are running tests selectively on the command line.</div><div><br></div><div>There are other uses which are more local to a single test module:</div><div><br></div><div>* Automatically skip all tests based on a condition. For example, all tests in a module interact with some external resource, so an autouse fixture skips all tests in that module automatically when some conditions are not met; using ``pytest.mark.skipif`` is not possible in that case because the check is not trivial and must be done inside a function.</div><div><br></div><div>* As a quick way to convert xUnit setup/teardown style to fixtures. For example:</div><div><br></div><div> class Test(unittest.TestCase):</div><div><br></div><div> def setUp(self):</div><div> self.instance = Instance()</div><div> self.window = Window()</div><div><br></div><div> def tearDown(self):</div><div> self.window.close()</div><div> self.instance.destroy()</div><div><br></div><div> def testStartup(self):</div><div> self.assertEqual(<a href="http://self.instance.name">self.instance.name</a>, 'Initial')</div><div><br></div><div> Sometimes one would like to use other pytest features which don't work with xUnit subclasses, like parametrization, but doesn't have the time/inclination to change the entire setup/teardown into separate fixtures. In those cases we execute unittest2pytest[2] in the module and change the ``setUp`` method into an autouse fixture as follows:</div><div><br></div><div> class Test:</div><div><br></div><div> @pytest.yield_fixture(autouse=True)</div><div> def setUp(self):</div><div> self.instance = Instance()</div><div> self.window = Window()</div><div> yield</div><div> self.window.close()</div><div> self.instance.destroy()</div><div><br></div><div> def testStartup(self):</div><div> assert <a href="http://self.instance.name">self.instance.name</a> == 'Initial'</div><div><br></div><div><br></div><div> I find the above a good trade-off specially if your test suite contains thousands of tests written in xUnit style.</div><div><br></div><div><br></div><div>Hope the above is useful! </div><div><br></div><div>Cheers,</div><div>Bruno.</div><div><br></div><div><br></div><div>.. [1]: <a href="https://pypi.python.org/pypi/pytest-mock">https://pypi.python.org/pypi/pytest-mock</a></div><div>.. [2]: <a href="https://pypi.python.org/pypi/unittest2pytest">https://pypi.python.org/pypi/unittest2pytest</a></div><div><br></div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jul 26, 2016 at 4:20 PM Brian Okken <<a href="mailto:variedthoughts@gmail.com">variedthoughts@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">If you use "autouse" fixtures, I'd like to know why.<div><br></div><div>Here are a few examples I can think of:</div><div><br></div><div>* Work that needs done before, between, or after each test run that doesn't affect the outcome of the test.</div><div> * Maybe we have long running suites and we want to update some reporting system whenever a test finishes.</div><div>* The system under test has error logs that need to be interrogated.</div><div> * The tests maybe should check these logs and fail if new errors are created. But just in case the test writer forgets, we can check error logs and assert if there's something there. This will cause the test to Error. Not as strong as a Fail, but better than missing the problem.</div><div><br></div><div>Are there more reasons?</div><div><br></div><div>Thanks,</div><div>Brian</div></div>
_______________________________________________<br>
testing-in-python mailing list<br>
<a href="mailto:testing-in-python@lists.idyll.org" target="_blank">testing-in-python@lists.idyll.org</a><br>
<a href="http://lists.idyll.org/listinfo/testing-in-python" rel="noreferrer" target="_blank">http://lists.idyll.org/listinfo/testing-in-python</a><br>
</blockquote></div>