Dreaming of new generation IDE
robert.kern at gmail.com
Wed Feb 3 23:27:43 CET 2010
On 2010-02-03 15:40 PM, Steven D'Aprano wrote:
> On Wed, 03 Feb 2010 06:42:52 -0800, Paul Rubin wrote:
>> One nice trick with static types is if you change
>> what the method does (even if its type signature doesn't change), you
>> can rename the method:
>> class.method2(string name, int count): # change 'method' to
>> and recompile your codebase. Every place in the code that called
>> 'method' now gets a compile time "undefined method" error that you can
>> examine to see if you need to update it. This is something you can't
>> catch with unit tests because the call sites can be in distant modules.
> I don't understand why that won't work with unit tests. If you change the
> name of a method, surely your unit tests will now start failing with
Let's say we have class "A" with a method named "foo" that we change to "bar".
We have another class "B" with a method that accepts and A() instance and calls
the .foo() method on it. It is perfectly reasonable (and often necessary) for
the unit test of class B to use a mock object instead of a real A() instance.
The unit test for class B will fail to catch the renaming of A.foo() to A.bar()
because it never tries to call .foo() on a real A instance.
Of course, in a static language, it's much harder to make mock objects to do
this kind of (very useful!) testing to begin with.
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
More information about the Python-list