Dreaming of new generation IDE

Robert Kern 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
>>     'method2'
>>
>> 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
> AttributeError?

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.

-- 
Robert Kern

"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 mailing list