Makes sense. Thanks! On Thu, Aug 24, 2017 at 5:20 AM Nick Coghlan <ncogh...@gmail.com> wrote:
> On 24 August 2017 at 08:20, Neil Girdhar <mistersh...@gmail.com> wrote: > > On Wed, Aug 23, 2017 at 3:31 AM Nick Coghlan <ncogh...@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 | ncogh...@gmail.com | Brisbane, Australia >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
