Makes sense. Thanks! On Thu, Aug 24, 2017 at 5:20 AM Nick Coghlan <ncoghlan@gmail.com> wrote:
On 24 August 2017 at 08:20, Neil Girdhar <mistersheik@gmail.com> wrote:
On Wed, Aug 23, 2017 at 3:31 AM Nick Coghlan <ncoghlan@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@gmail.com | Brisbane, Australia