[Python-ideas] Please consider adding context manager versions of setUp/tearDown to unittest.TestCase

[Nick Coghlan]

On 24 August 2017 at 08:20, Neil Girdhar <mistersheik at gmail.com> wrote:
> On Wed, Aug 23, 2017 at 3:31 AM Nick Coghlan <ncoghlan at gmail.com> wrote:
>> However, PEP 550's execution contexts may provide a way to track the
>> test state reliably that's independent of being a method on a test
>> case instance, in which case it would become feasible to offer a more
>> procedural interface in addition to the current visibly
>> object-oriented one.
>
> If you have time, could you expand on that a little bit?

unittest.TestCase provides a few different "config setting" type
attributes that affect how failures are reported:

- self.maxDiff (length limit for rich diffs)
- self.failureException (exception used to report errors)
- self.longMessage (whether custom messages replace or supplement the
default ones)

There are also introspection methods about the currently running test:

- self.id() (currently running test ID)
- self.shortDescription() (test description)

And some stateful utility functions:

- self.addSubTest() (tracks subtest results)
- self.addCleanup() (tracks resource cleanup requests)

At the moment, these are all passed in to test methods as a piece of
explicit context (the "self" attribute), and that's what makes it hard
to refactor unittest to support standalone top-level test functions
and standalone assertion functions: there's currently no way to
implicitly make those settings and operations available implicitly
instead.

That all changes if there's a robust way for the unittest module to
track the "active test case" that owns the currently running test
method without passing the test case reference around explicitly:

- existing assertion & helper methods can be wrapped with
independently importable snake_case functions that look for the
currently active test case and call the relevant methods on it
- new assertion functions can be added to separate modules rather than
adding yet more methods to TestCase (see
https://bugs.python.org/issue18054 for some discussion of that)
- given the above enhancements, the default test loader could usefully
gain support for top level function definitions (by wrapping them in
autogenerated test case instances)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia