[TFUI] GUI testing using Capture playback

[ reposted from news:comp.software.testing ]

tester69 wrote:

> I am implementing a C-R tool to perform GUI testing. As i went through
> the available information ; i came to know that most of the already
> implemented C-R tools are specific to some GUI toolkits.

If they were not specific, they would be fragile. Early CR tools broke
if you moved a button. The tool memorized mouse pointer locations, and
replayed these.

GUI Toolkits decouple GUI behavior from appearance. That's why they
have geometry managers and form painters. So if you move a button, the
event handler inside the application doesn't need to move too. Early
CR broke when applications upgraded.

Modern CR bonds with some control property, so if you move the control
and don't change the property, the CR tool can find it. Hence, CR
tools must be specific to their GUI Toolkits. The more generic, the
more fragile.

Generic tools tend to put a great distance between a test case and a
target application. Distance is bad.

> First i would like to learn more all that happens from the point the
> user clicks a mouse( or presses a keyboard) and the event shows its
> effect on the interface(i.e. about how events reach a GUI after a user
> performs an event). Pointers or links to web tutorials ( which are
> somewhat detailed ) would be helpful.

GUIs exist to decouple internal business logic from users. "Decouple"
means you can change some code without afflicting other code. Business
logic is logical, sequential, and relatively exact. Users, by
contrast, are illogical, squirrelly, and haphazard. So the GUI Toolkit
takes each input from a user and pipes it into an "event queue". All
GUIs have an event queue of some type.

Code in the GUI Toolkit, and in your application's GUI Layer, pops
events from these queues, and processes each one. The goal is to
convert illogical and random events into logical and sequential ones,
so many events are thrown away. The GUI Toolkit processes low-level
events, such as raw mouse movements, into cooked events, such as the
mouse poiner's position on the screen. Then the toolkit compares
cooked events to an object model of windows, forms, and controls. If
the mouse moved over a control, the toolkit sends a "mouse moved"
event to that control's handler. Most controls throw most processed
events away, and some few change their appearance as the mouse moves
over them.

Ideally a test should perform the equivalent of looking and and
driving a GUI, to confirm its appearance and behavior. This is what CR
tools offer - the automated ability to see and drive a GUI, like a
little robot running it.

> Secondly i would like to implement a generic tool, that can access all
> GUIs. Is there a way out for this?

Why?

As a business assessment, that sounds very lucrative. So if The Big
Kids, LLC, have not done it yet, it might not be possible. Did you
mean all GUIs on all of the Web, Un*x, MS Windows, Mac, Palm, WAP,
etc? If you meant all GUIs on Windows, then they must work at the
<winuser.h> level. So a CR tool that bonds to a property of a control,
such as its resource ID, must bond at a lower level than some GUI
Toolkits on Windows permit programmer control. Some Toolkits, such as
a Web browser, might change the resource ID on the fly, while
preserving some higher level control property. So the less fragile
your CR tool, the more closely it must bond with a specific GUI
Toolkit.

Let's get even closer to a specific application, bypassing CR, and see
how far we can go.

Here's a test for a GUI feature, written in the same language as the target:

    TEST_(TestSanskrit, caption)
    {
    
        CStringW caption;
        m_aDlg.GetWindowText(caption);

        CStringW expect =
                L"\x0909\x092A\x0915\x094d\x0930\x092e\x0903";
                     // upkraamaH-project

        CPPUNIT_ASSERT_EQUAL(0, lstrcmpW(expect, caption));
        
        expect = L"\x0924\x094d\x0930\x093e";  //  traa-save
        m_aDlg.GetDlgItemText(IDOK, caption);
        CPPUNIT_ASSERT_EQUAL(0, lstrcmpW(expect, caption));
        
     //   revealFor("phlip");

    }

The TEST_ macro creates a test case called Test_TestSanskrit_caption.
This inherits from a class TestSanskrit a member m_aDlg ("member a
dialog"). Each time that case runs it constructs a new dialog. The
case then extracts this dialog's title bar, in UCS-16, and asserts
that it is glyphically equivalent to the Sanskrit word "upkraamaH",
meaning Project. (This is just a sample project.) The test expresses
the Sanskrit word in raw Unicode, \x0909\x092A... etc. Then the test
checks that the Save button says "traa".

The function lstrcmpW(), on Win32, compares that two strings look the
same, regardless how their Unicode glyphs compose. The
harmless-looking glyphs ñ might be one character or two, an n and a
composing ~. lstrcmpW() normalizes these situations and returns true
if two strings would look the same when printed, regardless of their
binary representations.

So lstrcmpW() is an example of a technique, close to the application,
that accurately simulates looking at a GUI.

If you invented a CR tool that can "access all GUIs", it must handle
Sanskrit, Kannada, Manchu, Axumitic Geez, and so on. All of them, with
all their support libraries.

By contrast, a test rig written in the same language as the tested
application, using the same systems and libraries, will support and
synergize with its target. A serious Sanskrit project would use
lstrcmpW() freely on both the test and code side, and would wrap it
into application-specific modules, reducing the labor of both testing
and coding.

The effort of building an application-specific test rig, in parallel
with its tested application, is always lower than the effort of
forcing some generic test rig to agree with your application over all
these specific details.

-- 
  Phlip
  http://flea.sourceforge.net/resume.html


------------------------ Yahoo! Groups Sponsor --------------------~--> 
<font face=arial size=-1><a href="http://us.ard.yahoo.com/SIG=12hs48sau/M=362335.6886445.7839731.1510227/D=groups/S=1705007207:TM/Y=YAHOO/EXP=1123435468/A=2894361/R=0/SIG=13jmebhbo/*http://www.networkforgood.org/topics/education/digitaldivide/?source=YAHOO&cmpgn=GRP&RTP=http://groups.yahoo.com/">In low income neighborhoods, 84% do not own computers. At Network for Good, help bridge the Digital Divide!</a>.</font>
--------------------------------------------------------------------~-> 

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/