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