<div dir="ltr">Makes sense. Thanks! </div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 24, 2017 at 5:20 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 24 August 2017 at 08:20, Neil Girdhar <<a href="mailto:mistersheik@gmail.com" target="_blank">mistersheik@gmail.com</a>> wrote:<br>
> On Wed, Aug 23, 2017 at 3:31 AM Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>> However, PEP 550's execution contexts may provide a way to track the<br>
>> test state reliably that's independent of being a method on a test<br>
>> case instance, in which case it would become feasible to offer a more<br>
>> procedural interface in addition to the current visibly<br>
>> object-oriented one.<br>
><br>
> If you have time, could you expand on that a little bit?<br>
<br>
unittest.TestCase provides a few different "config setting" type<br>
attributes that affect how failures are reported:<br>
<br>
- self.maxDiff (length limit for rich diffs)<br>
- self.failureException (exception used to report errors)<br>
- self.longMessage (whether custom messages replace or supplement the<br>
default ones)<br>
<br>
There are also introspection methods about the currently running test:<br>
<br>
- <a href="http://self.id" rel="noreferrer" target="_blank">self.id</a>() (currently running test ID)<br>
- self.shortDescription() (test description)<br>
<br>
And some stateful utility functions:<br>
<br>
- self.addSubTest() (tracks subtest results)<br>
- self.addCleanup() (tracks resource cleanup requests)<br>
<br>
At the moment, these are all passed in to test methods as a piece of<br>
explicit context (the "self" attribute), and that's what makes it hard<br>
to refactor unittest to support standalone top-level test functions<br>
and standalone assertion functions: there's currently no way to<br>
implicitly make those settings and operations available implicitly<br>
instead.<br>
<br>
That all changes if there's a robust way for the unittest module to<br>
track the "active test case" that owns the currently running test<br>
method without passing the test case reference around explicitly:<br>
<br>
- existing assertion & helper methods can be wrapped with<br>
independently importable snake_case functions that look for the<br>
currently active test case and call the relevant methods on it<br>
- new assertion functions can be added to separate modules rather than<br>
adding yet more methods to TestCase (see<br>
<a href="https://bugs.python.org/issue18054" rel="noreferrer" target="_blank">https://bugs.python.org/issue18054</a> for some discussion of that)<br>
- given the above enhancements, the default test loader could usefully<br>
gain support for top level function definitions (by wrapping them in<br>
autogenerated test case instances)<br>
<br>
Cheers,<br>
Nick.<br>
<br>
--<br>
Nick Coghlan   |   <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>   |   Brisbane, Australia<br>
</blockquote></div>