shawnbrown / datatest

Tools for test driven data-wrangling and data validation.
Other
294 stars 13 forks source link

More Magic Removal (assertValid(), etc.) #20

Closed shawnbrown closed 7 years ago

shawnbrown commented 8 years ago

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:

  1. Create _compare...() functions to build collection of differences for mappings, sequences, sets, etc. (see #24).
  2. Create an assertValid() method that wraps the _compare...() functions (see #25).
  3. Create allowances to handle new mapping differences (see #23).
  4. Add pass-through behavior to assertValid() to replace the more magical helper methods like assertSubjectSum(), et al (see #26).
  5. Remove all of the assertSubject...() methods add them to the backward compatibility sub-package (see #27).
  6. Remove the assertEqual() wrapper and add it to backward compatibility sub-package (see #28).
  7. Update allowance wrappers and class names, move old implementations to backward compatibility sub-package (see #30).
  8. 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)
shawnbrown commented 7 years ago

Done: This issue detailed many of the ideas guiding the simplified, more flexible, and more consistent API that was introduced in version 0.8.