From: Dan North <dan@...>
Date: 2003-09-04T23:35:12+09:00
Subject: Re: [OT] Unit Tests and Encapsulation

I heard an interesting take on testing an implementation of an 
interface. Your test case is testing the behaviour or state of the 
_implementation_, but the rest of the world will only use the 
implementation through its _interface_. So by definition, any client 
code will only call interface methods (since they are the only ones it 
knows about) so it is irrelevant whether some other, 
implementation-specific, methods are public or not.

So your test case can ask all sorts of implementation-specific 
questions, and these will be hidden from any client code that only 
refers to the object via its interface methods.

It's another instance of duck-typing - the client only knows it's a Duck 
with a quack method. Only our test case knows it's a DuckOnAStick and to 
test the has_stick? method.

Cheers,
Dan

Michael Campbell wrote:

>>The problem is that once you have constructed the path, there is no
>>way in the public interface (at least not at the moment) for you to
>>    
>>
>go
>  
>
>>back and examine the points in the path.
>>
>>What that means is that in unit testing the drawing commands, there
>>is 
>>no way for a class outside of the BezierContour class to make sure
>>that 
>>the commands were recorded properly short of drawing the path and 
>>comparing the resulting picture with a previously verified picture 
>>(ick!)
>>    
>>
>
>There are a couple ways I've used in the past to solve this sort of
>problem.
>
>1. You don't test it.  I try to avoid this option.
>
>2. You modify the testee class to allow some sort of querying done
>with its innards.  Less than ideal.  (With Java, however, one can
>make these methods "package" visibility, so at least only classes in
>the same package can "see" them.)
>
>3. You make a new method that doesn't allow inspection of private
>data, but allows one to pass *IN* data, and this method will tell you
>if it's correct.  Something like:
>
>class Curve {
>  private:
>    Point[] _points;
>    ...
>
>  public:
>    boolean match(Point[] testPoints) {
>      // check here to see if all the testPoints match the values
>      // in _points
>      ...
>    };
>
>    void otherCoolMethod() { ... };
>};
>
>Then your unit test can simply call the method in question, and PASS
>IN a set of points that it thinks your curve should have.  The Curve
>instance then tells you (via the match() method) if that's right,
>rather than having the Curve instance pass its Points _out_ and have
>the test class verify them.
>
>__________________________________
>Do you Yahoo!?
>Yahoo! SiteBuilder - Free, easy-to-use web site design software
>http://sitebuilder.yahoo.com
>
>
>  
>

-- 
Dan North
http://www.thoughtworks.com