[Zope3-dev] mangled names in tests

[Jim Fulton]

Jeremy Hylton wrote:
> I've seen an idiom in several different unittests that I don't
> understand.  The tests all involve an abstract test class written
> against the interface.  The abstract class expects to be mixed in with
> a class that defines a method to create an instance of the interface
> being tested.
> 
> Example:
> 
>     class IFoo(Interface): pass
> 
>     class TestIFoo: pass
> 
>     class TestIdempotentFoo: pass
> 
> The TestIFoo class expect that TestIdempotentFoo is going to define
> some method to return an object implementing IFoo.  The idiom is see
> is to name that method _TestIFoo__new.  This is the mangled form of
> __new in TestIFoo.

Yes, this is my fault. Tres hates it too and has insisted that I stop
using it. :)


> I propose that we change it to _new() or, in cases where one concrete
> test class will mixin several abstract test classes, _testIFoo().  I
> think this is much clearer than using a mangled name for something
> that isn't a private name at all.

I suggest instead: _newIFoo()

> I haven't found a case where _newIFoo() is actually needed, so maybe
> that's a YAGNI.

I have, so it's not a YAGNI.

OK, so let's agree that we won't use mangled names this way anymore.
In general, I suggest that when a testing framework requires a
method to be defined that:

- It documents this requirement in it's doc string. (I failed to do this
   in a numner of cases. Bad me.)

- The names required reflect the framework in some way (e.g. _newMapping
   _sampleMappingData)

- The names required should begin with a single underscore to indicate that
   they are methods needed by (private too) an inherited framework
   (like C++ protected).

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org