Apparently, Scott Thompson recently wrote:

>> Most of the time, if you're having trouble unit-testing a class, that
>> means the class is doing too much.
>
> Well... I don't think that is the case in this instance.  The class
> simply records a series of drawing commands (moveto, lineto, curveto,
> and close) and at some point in the future can play back that sequence
> on a drawing context.
>
>> 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.
>
> Not exactly.  It receives a series of drawing commands and can replay
> them into a drawing context later on.
>
>> Who receives these commands?
>
> On Operating System drawing context later receives them from the
> contour.
>
>> Can you write some sort of
>> MockPostScript that records the commands it receives, and then you can
>> look into that in your unit test?
>
> Unfortunately, the drawing context that the drawing commands play out
> in is owned by the operating system and I don't have the ability to
> duplicate it's functionality enough to create a mock drawing context
> that could verify the points.  Perhaps I need to abstract the OS
> drawing context one level (at least at testing time) then I could
> insert my verification code in the intermediate layer between the
> contour class and the operating system's drawing context.

This isn't directly related to this particular problem, but here is an
open question for the group:

In this particular case, there are some good ideas of how to unit test it.
But in general, it seems like things start breaking down the closer you
get to a one-way data transfer. In this case, it's tricky because we say,
well, once we pass it to the operating system's drawing context, how do we
know it's correct afterward? We can test it before hand with many middle
layers, but we can't [easily] test it afterward.

What about some other extreme cases? Like, a class that plays a sound on a
speaker? How do you unit test that? Or, likewise, any class that
interfaces with the "world" "outside" your control? What if they are so
complex that you can't easily or acurately model them? What about output
that "needs" human interaction?

Anyway, I know what *my* answers to these questions have been on some
projects (and unfortunately enough, it's often "just don't bother
testing"), but I'm curious what people's thoughts on this are. =)

Wes