Art of Unit Testing: Part 2

[John Roth]

"Jesse F. W" <jessefw at loop.com> wrote in message
news:mailman.998679338.16044.python-list at python.org...
> Dear Python-list-iners,
> I have another Testing related question.  How are unit tests done
> when the units to be tested get lots of information from nested
> objects, e.g. (in a method of a class to be tested):
> if self.app.cnt_player.battle.kind=='stop':
> how would this be tested?

> Should you simulate the parts of the app object that are needed?
> In that case, you have to update the tests when you use parts of the
> app object you did not use before.  Should you use a real app
> object?  Then you are not really doing _unit_ testing, and it would
> make running detailed tests very difficult?  Is there another solution
> that anyone knows about?

That's part of "Design for Testing." The short answer is that
if the object you are testing needs an infrastructure, you have to supply
it.
It's preferable to supply the "real" infrastructure from the project, but
sometimes it isn't feasible.

If your class needs a player object for it to make sense, then you need
to supply such an object, properly updated. FREX - a project I'm
working on needs a date to start a fairly involved astronomical
calculation. I need to supply a properly initialized date object, or it
won't work.

Designing for test suggests that my date object be fully tested first,
then it can simply be used as a component in later tests. It also
suggests that I keep the dependencies as simple as possible. My date
object, in certain circumstances, needs a place object to determine
the time zone, which in turn needs a time zone change atlas to determine
which time variation applied. For higher level tests, I therefore always
specify GMT, which doesn't need the location information. I'm not,
after all, testing the date object, simply using it.

If you're having trouble, I'd suggest that you look at the design with
the question "how am I going to test this?" in mind. You may want to
refactor some of it.

John Roth

> Thank you all for your time,
> Jesse W
>