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 -- http://mail.python.org/mailman/listinfo/python-list
