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