How about "pure virtual methods"?

[Noam Raphael]

Jp Calderone wrote:
>   This lets you avoid duplicate test code as well as easily test
> new concrete implementations.  It's an ideal approach for frameworks
> which mandate application-level implementations of a particular 
> interface and want to ease the application developer's task.
> 
>   Jp

It's a great way for sharing tests between different subclasses of a 
class. Thank you for teaching me.

However, I'm not sure if this solves my practical problem - testing 
whether all abstract methods were implemented. I think that usually, you 
can't write a test which checks whether an abstract method did what it 
should have, since different implementations do different things. I 
don't even know how you can test whether an abstract method was 
implemented - should you run it and see if it raises a 
NotImplementedError? But with what arguments? And even if you find a way 
to test whether a method was implemented, I still think that the 
duplication of code isn't very nice - you have both in your class 
definition and in your test suite a section which says only "method 
so-and-so should be implemented."

I think that making abstract methods a different object really makes 
sense - they are just something else. Functions (and methods) define 
what the computer should do. Abstract methods define what the 
*programmer* should do.

Again, thanks for enlightening me.
Noam