[TFUI] Mock Graphics

TFUI:

A "Mock Object" is a Test Fixture that tested
Production Code thinks is a real application object.
Imagine hunters placing decoys of ducks into a pond.
Real ducks obey their instinct to flock with things
that look like ducks. But decoy ducks have no meat
inside. Similarly, a test may construct a decoy that
looks like a real object, and place it into the pond
of production objects, to see how they interact with
it. But Mock Objects have little or no logic inside.

Some Mock Objects, in dynamic languages, automatically
generate any methods their clients request. In our
hunting parable, the ducks fly away, and the decoy
sprouts real wings to follow them. Some Mock Objects
take a reference to a real object, to mock all its
members. In our parable, a biomimetic decoy resembles
any required waterfowl.

If Production Code must call a sequence of methods on
the Mock Object, it can record each one in a Log
String, and the Test Case can then assert the sequence
was correct.

A Paint() event, to paint a custom control, or to
customize an existing control, typically dispatches a
sequence of graphics driver commands. To constrain
one, we must mock the graphics driver.

Here's an example of this technique, in fictitious
Java:

    public TestGraphs extends TestCase
    {
        public void testDrawLine()
        {
            Graph graph = new Graph();
            Graphics mock = new Mock(Graphics.class);
            graph.Paint(mock);

            assertEquals("drawPolyLine(200, 100, 100,
200);",
                         mock.getLogString() );
        }
    }

It implies that the Paint() event drew a diagonal
line. However, if that event called more methods, the
Log String could grow long and fragile. This technique
trades an impossible situation-mechanical review of
some inscrutable Paint() method-for a very hard
situation, a Parsed Fuzzy Match.

Some graphics drivers provide the option to record all
their commands to a file instead of display them;
these systems come with Mock Graphics built-in.

Use this technique as sparingly as you invent custom
controls. Prefer advanced canvases, such as TkCanvas,
that Query Visual State as flexibly as they manipulate
it. But as you use more Mock Graphics, you will write
more Test Fixtures that support Fuzzy Matches on their
Log Strings.

Ideally, sloppy refactors that change the order of
graphics commands, without changing appearances, would
not fail these tests. Test Fixtures could interpret
the commands and ensure the result still looks the
same. But another fix for this problem is to not
refactor sloppily. Remember to keep all your ducks in
a row.


=====
Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces


		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail 


------------------------ Yahoo! Groups Sponsor --------------------~--> 
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
http://us.click.yahoo.com/L5YrjA/eSIIAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~-> 

To unsubscribe, email:
TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org
 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/TestFirstUserInterfaces/

<*> To unsubscribe from this group, send an email to:
     TestFirstUserInterfaces-unsubscribe-hHKSG33TihhbjbujkaE4pw@public.gmane.org

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/