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

[Neil Girdhar]

Makes sense. Thanks!

On Thu, Aug 24, 2017 at 5:20 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170824/9cc44652/attachment-0001.html>