[TIP] Why do you use "autouse" fixtures?

[Bruno Oliveira]

Hi Brian,

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.

We have some global autouse fixtures which live in plugins/conftest files
and are applied to the entire test suite:

* Set global test suite configuration by using session-scope autouse
fixtures that:

  * Disable crash dialogs on Windows;
  * Set environment variable related to testing (for example: "TESTING=1");

* 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);

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.

There are other uses which are more local to a single test module:

* 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.

* As a quick way to convert xUnit setup/teardown style to fixtures. For
example:

    class Test(unittest.TestCase):

        def setUp(self):
            self.instance = Instance()
            self.window = Window()

        def tearDown(self):
            self.window.close()
            self.instance.destroy()

        def testStartup(self):
            self.assertEqual(self.instance.name, 'Initial')

  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:

    class Test:

        @pytest.yield_fixture(autouse=True)
        def setUp(self):
            self.instance = Instance()
            self.window = Window()
            yield
            self.window.close()
            self.instance.destroy()

        def testStartup(self):
            assert self.instance.name == 'Initial'


  I find the above a good trade-off specially if your test suite contains
thousands of tests written in xUnit style.


Hope the above is useful!

Cheers,
Bruno.


.. [1]: https://pypi.python.org/pypi/pytest-mock
.. [2]: https://pypi.python.org/pypi/unittest2pytest



On Tue, Jul 26, 2016 at 4:20 PM Brian Okken <variedthoughts at gmail.com>
wrote:

> If you use "autouse" fixtures, I'd like to know why.
>
> Here are a few examples I can think of:
>
> * Work that needs done before, between, or after each test run that
> doesn't affect the outcome of the test.
>     * Maybe we have long running suites and we want to update some
> reporting system whenever a test finishes.
> * The system under test has error logs that need to be interrogated.
>     * 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.
>
> Are there more reasons?
>
> Thanks,
> Brian
> _______________________________________________
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
> http://lists.idyll.org/listinfo/testing-in-python
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idyll.org/pipermail/testing-in-python/attachments/20160726/a3e48409/attachment.htm>