Exhaustive Unit Testing

[Fuzzyman]

On Nov 27, 4:32 pm, "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?
>
> Manu


Your experiences are one of the reasons that writing the tests *first*
can be so helpful. You think about the *behaviour* you want from your
units and you test for that behaviour - *then* you write the code
until the tests pass.

This means that your code is testable, but which usually means simpler
and better.

By the way, to reduce the number of independent code paths you need to
test you can use mocking. You only need to test the logic inside the
methods you create (testing behaviour), and not every possible
combination of paths.

Michael Foord
--
http://www.ironpythoninaction.com/