On 9/24/2010 10:17 AM, Daniel Stutzbach wrote:
On Thu, Sep 23, 2010 at 7:24 PM, Terry Reedy <tjreedy@udel.edu <mailto:tjreedy@udel.edu>> wrote:
Can this work? Split the current test suite for a concrete class that implements one of the ABCs into concrete-specific and ABC-general portions, with the abstract part parameterized by concrete class.
For instance, split test/test_dict.py into test_dict.py and test_Mapping.py, where the latter has all tests that test compliance with the Mapping ABC (or whatever it is called) and the former keeps all the dict-specific extension tests. Rewrite test_Mapping so it is not dict specific, so one could write something like
Reading the responses, I realized that I am already doing a simplified version of my suggestion for functions rather than classes. For didactic purposes, I am writing multiple implementations of multiple abstract functions. I embody a test for a particular function in an iterable of input-output pairs (where the 'output' can also be an exception class). I use that with a custom super test function that tests one or more callables against the pairs. It works great and it is easy to add another implementation or more pairs.
As a heavy user of the ABCs in the collections module, that would be awesome. :-) It would make my life a lot easier when I'm writing tests to go along with an ABC-derived class. I have 8 such classes on PyPi (heapdict.heapdict and blist.*), plus more in private repositories.
There is some code vaguely along those lines in the existing unit tests. For example, Lib/test/seq_tests.py contains tests common to sequences. However, that was written before collections.Sequence came along and the pre-2.6 definition of "sequence" only loosely correlates with a collections.Sequence.
Well, pick one existing test file, revise and extend and perhaps split, start a tracker issue with proposed patch, get comments, and perhaps commit it. If you do, add terry.reedy as nosy. -- Terry Jan Reedy