Most of the time, if you're having trouble unit-testing a class, that
means the class is doing too much. When I'm coding I find myself
constantly breaking down my code into small manageable classes -- not
only does this make my unit-tests short and simple, it also gives me
the added benefit of giving me a clearer, more focused understanding
of what I'm writing.

In the case of your BezierContour class, I have to ask: It generates a
series of PostScript commands (moveto, lineto, etc) and passes them
along. Who receives these commands? Can you write some sort of
MockPostScript that records the commands it receives, and then you can
look into that in your unit test?

In Ruby, this might look like:

class TestBezierCounter << RUNIT::TestCase
  def testDraw
    counter = BezierCounter.new( < some parameters here > )
    mockPostScript = MockPostScript.new
    counter.draw( mockPostScript )
    assert_equal( MockPostScript::MOVE_TO,
                  mockPostScript.commands[1].commandType )
  end
end

Francis

Scott Thompson <easco / mac.com> wrote in message news:<575F2D48-DE81-11D7-ACB3-000393803090 / mac.com>...
> This may be off-topic in a Ruby list, although I have noticed that a 
> lot of folks involved with Ruby are also fond of Unit Testing so it may 
> not be as off-topic as I think.
> 
> Anyway...
> 
> Being of the old guard, the ideas behind unit testing are fairly new to 
> me.  I'm giving it a shot just to see how things work out.
> 
> 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.
> 
> 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!)
> 
> One means of making a more meaningful Unit Test would be to allow the 
> unit test to access the points of the curve (the control polygon for 
> fellow math geeks) and verify that the resulting polygon matches the 
> one that the drawing commands should produce.  Adding the routine to 
> examine the control polygon, however, would be a violation of the 
> encapsulation (or more to the point the current design of the class 
> which states that the control polygon not be available) of the 
> BezierContour class.
> 
> Now one answer to this conundrum would be to include the methods to 
> access the control polygon ONLY when the testing code is compiled into 
> the application.  This would be roughly equivalent to having the Ruby 
> unit testing code extend the BezierContour class with methods to 
> examine the control polygon.
> 
> The question I have, however, is one of style.  Is this kind of class 
> extension often done in Unit Testing or is it more likely that the Unit 
> Test would only test the common public interface for the class.
> 
> Please feel free to respond off this list or cast your responses in a 
> Ruby Way (with all due respect to Hal) as this is somewhat off-topic.
> 
> Scott