From: "Mauricio Fernández" <batsman.geo@...>
Date: 2003-09-04T18:13:20+09:00
Subject: Re: [OT] Unit Tests and Encapsulation

On Thu, Sep 04, 2003 at 11:42:04AM +0900, Scott Thompson wrote:
> I was writing a test today on a class (prototyped in Ruby then 
> implemented in Objective-C++ for the final application) that manages 
> the points of a Cubic Bezier curve.   The theory of the class was that 
> the curve is constructed from a series of the classic moveto, lineto, 
> curveto, and close commands that those folks familiar with the 
> PostScript drawing model may be familiar with.
> 
> 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.

This might sound silly, but would it be possible to overload, say, #==
so that you can check whether the final state of your object matches
your expectations (with assert_equal)? You'd have to specify a format
to represent the state but at least you're not exposing the internals
so you would be free to modify them without breaking the tests.

> 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 
                    ========
When I see that I think of mock objects logging all drawing commands.
It might even make sense to just wrap the real objects in a delegator
and log all method calls.

IANAUTE (I am not a Unit Testing expert)

-- 
 _           _                             
| |__   __ _| |_ ___ _ __ ___   __ _ _ __  
| '_ \ / _` | __/ __| '_ ` _ \ / _` | '_ \ 
| |_) | (_| | |_\__ \ | | | | | (_| | | | |
|_.__/ \__,_|\__|___/_| |_| |_|\__,_|_| |_|
	Running Debian GNU/Linux Sid (unstable)
batsman dot geo at yahoo dot com

...and scantily clad females, of course.  Who cares if it's below zero
outside.
	-- Linus Torvalds