Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>> Your unit test should exercise the whole API promised by an
>>> implementation anyway, so often an explicit interface check is redudant
>>> (of course, it can't hurt). verifyClass() per se isn't bad, it's in fact
>>> a useful indicator, but having that it as a *sole* measure whether a
>>> class fulfills an interface or not is not sufficient (plus, in many Zope
>>> cases, verifyObject is better because attributes may only be initialized
>>> in __init__).
>>> The point why I think it's YAGNI is that we know the Zope 2
>>> implementations do implement the interfaces. After all, I derived the
>>> interfaces from the implementations by gutting out the code. And it's
>>> unlikely they'll change (although I might be wrong on this one, in which
>>> case you win :)).
>> When writing "test-first", I often start with only the 'verifyClass'
>> test, and an empty interface. Then as I flesh out the interface, the
>> test fails, reminding me to add the method / attribute. Yes, you still
>> need tests for the semantics, but the conformance test is still
>> valuable, because it "tests the tests" (an extra safety belt).
> Fair enough. Note the "extra": it shouldn't be your only one.
Right. The time recently when it paid off was after PyCon, when the
ZODB interfaces had been fleshed out. When the merging Five and Zope3
into Zope 2.8, one of the Zope3 classes had such a test, and blew up
becuase the interface had previously been incomplete. Fixing it was
easy, I think, but we would not have known about the problem without the
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -