Michael Foord <[email protected]> added the comment:
Here are my objections to the standard (but not widely used outside our own
tests) mixin pattern for base testcases (copied and pasted from issue 14408):
Because you then have classes that inherit from object calling methods that
clearly don't exist (until you subclass them *and* TestCase). It looks weird
and also means the classes can't be tested in isolation.
With a class decorator the code would *look* straightforward, and the hidden
attribute is just an implementation detail.
It still looks weird to see code calling methods that obviously don't exist,
and with no indication *at the call site* where they come from. Making it
clearer with naming would help: "TestThingMixin" or similar.
There are classes like this in the unittest test suite, and I was very confused
by them initially until I found where and how they were used. It is obviously
*not* a pattern that is widely known for test base classes, as we have this
problem of it not being done even in the standard library tests.
In contrast I think code similar to the following would be clear and readable
without knowing about multiple inheritance and the mixin trick:
@test_base_class
class SomeTestBase(TestCase):
...
Besides which, the mixin pattern won't *stop* working if we provide this extra
functionality - it would just be an alternative for those (like myself) who
think it impedes code readability. :-)
At this point we're off topic for the *specific issue*, and I'm fine with our
own standard library tests moving to use mixins to support standard unittest
invocation. I would suggest the base test cases include Mixin in their name to
make it clear how they should be used.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue14534>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
