Art of Unit Testing: Part 2

[Don Dwiggins]

Jesse W writes:
> 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?

The (overly) simple answer here is, "don't do that" (the code, not the
testing).  In the terms of Fowler's "Refactoring" book, it's a code smell.

For a better understanding of the reasons for avoiding this kind of object
structure navigation, see the "Law of Demeter" section in Brad Appleton's
"Introducing Demeter and its Laws" at
http://www.enteract.com/~bradapp/docs/demeter-intro.html

Also look at the discussion of this law/principle/guideline at
http://www.c2.com/cgi/wiki?LawOfDemeter.  About 2/3 down, you'll find
"Demeter and Unit Tests", which addresses your example.

Don't expect your reading to result in a simple "always do it this way"
algorithm.  You're getting into some serious object design issues, like
factoring responsibilities among objects, and defining object contracts.

-- 
Don Dwiggins                    "Solvitur Ambulando"
Advanced MP Technology
dwig at advancedmp.net