[TFUI] Temporary Visual Inspections

A common manual debugging technique is a lowly print
statement. You diagnose a problematic method by
printing the value of a local variable. Then you run
the program and inspect its output, watching a trace
of that variable’s value.

When you comment-out the print statement, to suspend
its output, you treated your program’s output like a
stream, with a little spigot, or valve, on your print
statement.

The event queue is also an I/O port. Fixtures that
regulate it to repress it can also release it,
allowing its event messages to flow through it.
Messages that command it to appear on the screen will
call its Paint() event handlers, and the tested window
pops up on your screen.

Toolkit methods that operate event queues can work in
blocking or non-blocking mode. When a method like
Tk.mainloop() blocks, it await new events, and control
flow doesn’t come out of that function.

A test fixture can exploit these queue behaviors to
temporarily reveal a populated tested window, for a
quick visual confirmation that its assertions are not
leading the test astray.

Here’s an example of this technique in action, under
minimal but full-featured test fixtures. This test
checks that a dialog, called m_aDialog, contains an
edit field called IDC_EDIT_ADDRESS_1, which contains a
deliberately whimsical value:

    TEST_(TestDialog, address_1)
    {
        CPPUNIT_ASSERT_EQUAL( "Heppy Land",
            m_aDialog.getText(IDC_EDIT_ADDRESS_1) );
    }

When I hit my One Test Button, I never see any
instances of the tested dialog, including the one
created inside TestDialog’s fixtures, just before that
case runs.

Now suppose I became suspicious. That test might
contain a false positive. Maybe the text is
accidentally very small. Maybe the text is at a
location outside its window borders. Maybe the text is
the same color as the background. We can’t test
everything, and no test can take the place of just
looking at a GUI.

Maybe the test only passes because it doesn’t take the
font into consideration. Maybe the dialog, for
whatever reason, uses a font that maps ASCII code
points into characters other than the Latin alphabet.
That test would pass that situation, when garbage-in
exactly matches garbage-out. The user can’t read the
text, but the test passes.

I want to see exactly what users see in that test’s
situation:

    TEST_(TestDialog, address_1)
    {
        CPPUNIT_ASSERT_EQUAL( "Heppy Land",
            m_aDialog.getText(IDC_EDIT_ADDRESS_1) );
        
        revealFor("phlip");
    }

When I hit my One Test Button and run all the tests,
this case temporarily calls a method from the base
TestDialog class. revealFor() opens the valve on our
event queue. The Paint() event (which here is the
WM_PAINT message) is released to command the dialog to
paint. I see it, in its tested state, with that
whimsical sample data populating it:

 [Project_________________________________-[]X]
 |                                <  Okay  >  |
 |  First Name: [ Ignatz     ]    < Cancel >  |
 |   Last Name: [ Mouse      ]                |
 |   Address 1: [ Heppy Land ]                |
 |   Address 2: [            ]                |
 |        City: [ Coconino   ]                |
 |       State: [ AZ         ]                |
 |         ZIP: [            ]                |
 +--------------------------------------------+

While that dialog is up, I could use <Alt+Tab> to
return to the editor, and I could change statements
there.

The dialog stays up until I manually close that
window, using the keyboard or the mouse.

After it closes, any statements after revealFor()
would run. All remaining cases run.

I "signed" the temporary statement,
revealFor("phlip"), to permit Continuous Integration.
The test fixture checks the current programmer’s name
before revealing. (Programmers using shared
workstations could reveal based on their workstation’s
name.) When I sign a Temporary Visual Inspection, then
integrate, other programmers can integrate and run
tests without seeing my windows.

All assertions before and after a Temporary fixture
must still test. During integration testing,
dismissing a revealed window must not skew test
results, or permit bugs to slip into the team’s common
codebase.
When I finish comparing my test’s opinion of visual
appearances to the real thing, I comment-out the
temporary line:

    TEST_(TestDialog, address_1)
    {
        CPPUNIT_ASSERT_EQUAL( "Heppy Land",
            m_aDialog.getText(IDC_EDIT_ADDRESS_1) );
        
     //   revealFor("phlip");  //  is the font
correct?
    }

Future edits may remove that comment, or it may remain
as a hint that this case once associated with special
concerns. I write comments to raise suspicion. In my
scenario, if that visual inspection had failed, or if
I felt fear, I would have added assertions to query
what glyphs the current font supports.

All assertions that Query Visual Appearances are
approximations. Use Temporary Visual Inspections to
confirm such queries. To catch false positives as
early as possible, reveal every window that uses new
kinds of queries. If such queries fail, research the
situation to write new fixtures that augment the
queries with more accurate results.


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


		
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
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/