[TIP] Why do you use "autouse" fixtures?
johannes.bornhold at gmail.com
Thu Jul 28 06:16:39 PDT 2016
> On 26 Jul 2016, at 21:14, 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?
* measuring / reporting
I've been doing this on occasion to get information
per test into an external system. In my case this was
the runtime, but also information about the memory
consumption per test.
Running the test suite over time I was able to graph this
information and observe how it changed over time.
* On module level: Reset user logs to a clean state
* On class level, they work like setup / teardown.
Preparing some class attributes which are then used
by multiple tests. Feels weird though, since I probably
could use the fixture as a parameter to the test function.
* DB session rollback
This is something I don't like too much, since it makes the
whole suite depend on a database being available. Still, it was
useful for me in at least one project.
* On session scope: Initialize parts of the application.
More information about the testing-in-python