From: Michael Campbell <michael_s_campbell@...>
Date: 2003-09-04T21:42:18+09:00
Subject: Re: [OT] Unit Tests and Encapsulation

> 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