Exhaustive Unit Testing

[Steven D'Aprano]

On Thu, 27 Nov 2008 08:32:12 -0800, 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, 

Naturally.


> 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?

"Private" methods in Python are only private by convention.


>>> class Parrot:
...     def _private(self):  # private, don't touch
...             pass
...     def __reallyprivate(self):  # name mangled
...             pass
...
>>> Parrot._private
<unbound method Parrot._private>
>>> Parrot.__reallyprivate
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: class Parrot has no attribute '__reallyprivate'
>>> Parrot._Parrot__reallyprivate
<unbound method Parrot.__reallyprivate>

In Python, the philosophy is "We're all adults here" and consequently if 
people *really* want to access your private methods, they can. This is a 
Feature, not a Bug :)

Consequently, I almost always use single-underscore "private by 
convention" names, rather than double-underscore names. The name-mangling 
is, in my experience, just a nuisance.



-- 
Steven