Exhaustive Unit Testing
james.harris.1 at googlemail.com
Sun Nov 30 16:24:07 CET 2008
On 27 Nov, 16:32, "Emanuele D'Arrigo" <man... at gmail.com> 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?
Difficult to say without seeing the code. You could post it, perhaps.
On the other hand a general recommendation from Programming Pearls
(Jon Bentley) is to convert code to data structures. Maybe you could
convert some of the code to decision tables or similar.
More information about the Python-list