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/
