Exhaustive Unit Testing

[Terry Reedy]

Emanuele D'Arrigo wrote:
> On Nov 27, 5:00 am, Steven D'Aprano
> <ste... at REMOVE.THIS.cybersource.com.au> wrote:
>> Refactor until your code is simple enough to unit-test effectively, then
>> unit-test effectively.
> 
> Ok, I've taken this wise suggestion on board and of course I found
> immediately ways to improve the method. -However- this generates
> another issue. I can fragment the code of the original method into one
> public method and a few private support methods. But this doesn't
> reduce the complexity of the testing because the number and complexity
> of the possible path stays more or less the same. The solution to this
> would be to test the individual methods separately, but is the only
> way to test private methods in python to make them (temporarily) non
> private? I guess ultimately this would only require the removal of the
> appropriate double-underscores followed by method testing and then
> adding the double-underscores back in place. There is no "cleaner"
> way, is there?

Use single underscore names to mark methods as private.  The intent of 
double-underscore mangling is to avoid name clashes in multiple 
inheritance.  If you insist on double underscores, use the mangled name 
in your tests.  'Private' is not really private in Python.

IDLE 3.0rc3
 >>> class C(): __a=1

 >>> C._C__a
1

Terry