OK, this ticket is a big deal and should allow for all sorts of added flexibility.
1. Create a general comparison-wrapper that wraps instances of any type (set, dict, int, str, etc.).2. Create an assertValid() method that handles comparisons for arbitrary objects (uses comparison-wrapper internally). This should handle object-to-object, object-to-callable, and object-to-regex comparisons.3. Remove the assertEqual() wrapper method and use addTypeEqualityFunc() to register a comparison function for the new wrapped type.4. Add pass-through behavior to assertValid() to replace existing magical methods (like assertSubjectSum(), et al).5. Remove all of the assertSubject...() methods (reimplement them in the backward compatibility sub-package using assertValid()).
[September 14th and October 6th edits, below]
After exploring different approaches for implementing this, I have settled on an alternate list of steps that allows for incremental progress and a simpler backward compatibility roadmap:
Create _compare...() functions to build collection of differences for mappings, sequences, sets, etc. (see #24).
Create an assertValid() method that wraps the _compare...() functions (see #25).
Create allowances to handle new mapping differences (see #23).
Add pass-through behavior to assertValid() to replace the more magical helper methods like assertSubjectSum(), et al (see #26).
Remove all of the assertSubject...() methods add them to the backward compatibility sub-package (see #27).
Remove the assertEqual() wrapper and add it to backward compatibility sub-package (see #28).
Update allowance wrappers and class names, move old implementations to backward compatibility sub-package (see #30).
Explore the possibility of optimized _validate...() functions for faster testing (short-circuit evaluation and Boolean return values) rather than using _compare...() functions in all cases (see #29).
Using assertEqual()...
self.assertEqual(9, 10)
...returns a unittest-style traceback that reads:
Traceback (most recent call last):
File "<stdin>", line 3, in test_example
AssertionError: 9 != 10
Using assertValid()...
self.assertValid(9, 10)
...should return a data-test style traceback:
Traceback (most recent call last):
File "<stdin>", line 3, in test_example
DataError: Deviation(-1, 10)
OK, this ticket is a big deal and should allow for all sorts of added flexibility.
1. Create a general comparison-wrapper that wraps instances of any type (set
,dict
,int
,str
, etc.).2. Create anassertValid()
method that handles comparisons for arbitrary objects (uses comparison-wrapper internally). This should handle object-to-object, object-to-callable, and object-to-regex comparisons.3. Remove theassertEqual()
wrapper method and useaddTypeEqualityFunc()
to register a comparison function for the new wrapped type.4. Add pass-through behavior toassertValid()
to replace existing magical methods (likeassertSubjectSum()
, et al).5. Remove all of theassertSubject...()
methods (reimplement them in the backward compatibility sub-package usingassertValid()
).[September 14th and October 6th edits, below]
After exploring different approaches for implementing this, I have settled on an alternate list of steps that allows for incremental progress and a simpler backward compatibility roadmap:
_compare...()
functions to build collection of differences for mappings, sequences, sets, etc. (see #24).assertValid()
method that wraps the_compare...()
functions (see #25).assertValid()
to replace the more magical helper methods likeassertSubjectSum()
, et al (see #26).assertSubject...()
methods add them to the backward compatibility sub-package (see #27).assertEqual()
wrapper and add it to backward compatibility sub-package (see #28)._validate...()
functions for faster testing (short-circuit evaluation and Boolean return values) rather than using_compare...()
functions in all cases (see #29).Using
assertEqual()
......returns a unittest-style traceback that reads:
Using
assertValid()
......should return a data-test style traceback: