Art of Unit Testing: Part 2

[Jesse F. W]

William Tanksley wrote:
> On Fri, 24 Aug 2001 11:51:07 -0700, Jesse F. W wrote:
<snip>
> >if self.app.cnt_player.battle.kind=='stop': how would this be tested?
> 
> It wouldn't -- it would be deleted and abhorred.  That's a violation
> of encapsulation and of the law of Demeter (google that if you don't
> know what it means).

	I have looked it up on google.  For the lurkers, (and my own 
greater knowledge), I will rephrase what I found:  The Law of 
Demeter means that you should have as few dots(in Python) in your 
code as possible.  You should make special functions to do 
whatever you need done, instead of just doing the thing where you 
need it done.(Yes, I know that's a sort of pejoritive way of putting it) 
:-) 

> The problem is that each object should have an interface to do
> everything it needs to do.  You shouldn't have to reach inside any
> object to inspect how it's doing its job.  The above code should look
> like 'if self.app.anyPlayersInStoppedBattles():' (I'm assuming that's
> an appropriate name).
>
> However, your question still remains: how do you unit test objects
> which are supposed to delegate operations to other objects?  The
> answer is that you write the unit test without assuming any
> delegation.  That method you mentioned should work whether or not
> delegation is happening; and your test won't care, because it only
> tests the method, not the implementation.

	Now this, I don't understand(yet).  What do you mean, "delegate 
operations to other objects?"  What the example code I included 
above does is check wheather the current player in the game is 
stopped.  I don't see how the method could work if there was no 
current player object.  Also, please say more about your last 
sentence, about testing only the method, not the implementation.

	Thank you very much,
		Jesse W