How about "pure virtual methods"?

[Noam Raphael]

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
> Technician/Programmer
> Credit International
> 

Thanks for your comment. You're welcomed to reply if you don't agree.
Noam