The Turtle Dependency

Let's look at an example.

Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing?

Well, you can run it and compare the screen with a standard screen snapshot, but let's admit it: tests like this are expensive to run and are fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your standard images!).

It would be too painful if all your tests are like this - in fact, you'd probably won't run them at all because of the productivity hit. Fortunately, you learned about Object Oriented Design and abstraction, and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in a class (say, Turtle) and code against that class.

class Turtle {  

   //...

  ~Turtle() {}

 void PenUp() {...};

 void PenDown() {...};

 void Forward(int distance) {...};

 void Turn(int degrees) {...};

 void GoTo(int x, int y) {...};

 int GetX() {...};

 int GetY() {...};

};

You can control whether the turtle's movement will leave a trace using PenUp() and PenDown(), and control its movement using Forward(), Turn(), and GoTo(). Finally, GetX() and GetY() tell you the current position of the turtle.

Your program will normally use the real class. In tests, you can use a fake implementation instead. This allows you to easily check what drawing primitives your program is calling, with what arguments, and in which order. Tests written this way are much more robust (they won't break because your new machine does anti-aliasing differently), easier to read and maintain (the intent of a test is expressed in the code, not in some binary images), and run much, much faster.

Let's see how we can fake the Turtle class.