From: Warren Brown <wkb@...>
Date: 2003-09-05T02:33:39+09:00
Subject: Re: [OT] Unit Tests and Encapsulation

Scott,

> 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.

    First off, as other posts have pointed out, these types of problems are
usually avoided by writing the tests first.

    Now, to answer your question directly, when a test case needs to dig
into the internals of a class for some reason, I have the test case subclass
the original class, then add the methods that it needs to probe the class.
For example:

Class TestBezierContour < BezierContour
  attr_reader :mypath
  def getBoundingRect
    <code to calculate the bounding rectangle>
  end
end

    Of course you could have the test case just open up the original class
and add these methods, but I find it somehow cleaner to subclass.  The main
point is, you can leave the code in the original class pristine, and still
have the test case reopen or subclass it to suit your testing needs.

    However, in this case and other cases where a class has a one-way flow
of information to some other non-testable component (operating system,
third-party library, etc.), I think the better way to test is to encapsulate
the non-testable component in its own simple, "thin" class.  This also
offers some protection when the non-testable component changes (operating
system upgrade, new release of third-party library).  Test cases can now be
written for the original class using a mock object for the non-testable
component.  Now, the new "thin" class may still be difficult to test, but in
theory there will not be much code in the class, and simple test cases will
probably suffice.

    I hope this helps.

    - Warren Brown