How about "pure virtual methods"?
noamr at remove.the.dot.myrea.lbox.com
Wed Dec 22 01:27:35 CET 2004
Jeff Shannon wrote:
> Except that unit tests should be written to the *specification*, not the
> implementation. In other words, forgetting a complete method would
> require that you forget to write the method, *and* that you failed to
> translate the specification into unit tests *for that same method*.
You are absolutely right - but when you are not that tidy, and don't
have a written specification apart from the code, it would be natural to
go over each method in the class definition, and write a test to check
if it does what it should. I'm not saying that it's the ideal way, but
it is not that bad, usually.
> In the context of changing an existing interface, a unit-testing
> scenario would mean that, instead of installing a "pure virtual" method
> on a base class, you'd change the unit-tests to follow the new
> specification, and then write code that would pass the unit tests. If
> you are subclassing from a common base, then you'd only need to change
> the unit test for that common base class (presuming that all derived
> classes would run those unit tests as well).
The problem is that I couldn't write a general unit test, since the base
class wasn't instantiable - there wasn't even any point in making it
instantiable, since every subclass was constructed with different
argument definition. They were just required to provide some methods
(check whether they contain an object, for example) - I don't know how
to write a unit test for such a base class, or what does it mean. (Well,
it may mean: check whether all the required methods exist, but come on -
that's exactly the idea of my suggestion. There's no point in having to
write the list of required methods another time).
> Jeff Shannon
> Credit International
Thanks for your comment. You're welcomed to reply if you don't agree.
More information about the Python-list