Re: Automated Testing tools

Ravi wrote:

> 1. Any good resources/tools for automated testing
> tools for 
> SWT/Swing for User acceptance testing ? I have
> looked only at Abbot 
> and basic Robot framework.
> 2. Is it worth testing the GUI or just test the
> model ?

Acceptance tests are not GUI tests, and vice versa.
But testing a GUI is worthwhile, unless you want bugs
in the layer closest to your users.

Thibaud Bouquely wrote:

> But we have too some component for the GUI
> of ours applications (Grid, edit,
> group box, check box, etc. ...) for the
> grid, for exemple, we have may be
> 9000 lines of codes !!!

Why didn't you get a 3rd party grid?

("Because we didn't feel like it" is a valid
answer...)

> We develop this tool box with Delphi for seven
> years. and we want now
> developp "from crach" a new tool box on .NET
> platform and C# language. I
> want analyse how can I construct a strong
> test platform for this new ToolBox
> and make it on the start of this new project.

Excellent.

> NUnit seems the perfect tool, I can use too
> NCover to see the good quality
> of NUnit test, and may be some other tools
> to analyse the complexity of the
> code
> ** BUT **
> for the GUI component, I have no idea to
> realize this project.
> For exemple : how can I simulate the user action
> of the component ? If I
> change the color of something, How can I be
> sure the color is changed too ?
> etc. etc. etc. ....

The problem here is GUI Toolkit vendors compete by
adding wizards and form painters that interfere with
agility. A GUI is hard to test, but too easy to
refactor. GUI Toolkit documentation will reinforce how
to use a wizard to promote vendor-lockin; not how to
abuse a window the way tests need.

Break the problem down into parts:

 - One Button Testing
    some GUIs couple with their editors

 - Just Another Library
    window objects come with side-effects
    that break a test run, such as popping 
    up a window.

 - Query Visual State
    window objects don't come with methods
    that query what a window looks like.
    Any simulation (such as calling Production
    Code to Set a property, then Getting that
    property and asserting it's same value) have
    a risk of not strictly revealing window
    state, especially if the window is not painted 
    yet

 - Simulate a User
    send the kinds of messages to the window
    that it would have received if it were displayed
    and someone clicked on it or edited it

There are two kinds of GUI development; re-using
controls, and writing controls. To build a grid, you
re-use scroller bars, an array of edit fields, etc.
Controls for desktop GUI Toolkits use a data model
that buffers all state in memory before painting it
when a window displays.

Writing controls requires MockGraphics, another topic
entirely.

To test, provide Just Another Library by breaking the
window's event loop. Build a window object in memory,
put your controls on it, call Production Code to
manipulate them, query their properties to see if they
might have the correct values, then destroy the
windows without painting them.

Each test case you write has a powerful latent
temprorary ability. If you write a function called
'reveal(win)', you can temporarily adjust the test to
un-break the event loop, call Application.run() or the
equivalent, and display that window.

 - Treat I/O like a Spigot
    For each kind of window in your project
    build re-usable test code that displays the
    window temporarily

After you close such a window, other tests should run
cleanly.

These are very hard fixtures to write when all the
documentation for GUI Toolkits is geared towards
ensuring windows display on the screen or die trying.
We need many quiet tests, not a few obnoxious ones.

After you have a 'reveal(win)' method, call it each
time you write a new kind of test that Queries Visual
State, to check that the test is not passing due to a
bug in the window's property system. Call it
temporarily to click on a window, hit breakpoints in
the code, and learn the most accurate way to simulate
a user.

Many esthetic decisions don't need tests. One can
temporarily call 'reveal(win)' after each tweak, to
tune appearances. Just as TDD works by making 1~10
edits and testing, authoring visual appearances out of
tests works by making a few adjustments, predicting
the result, and viewing the output window, populated
with sample data, to confirm each change.


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


	
		
__________________________________
Do you Yahoo!?
Friends.  Fun.  Try the all-new Yahoo! Messenger.
http://messenger.yahoo.com/ 


To Post a message, send it to:   [email protected]

To Unsubscribe, send a blank message to: [email protected]

ad-free courtesy of objectmentor.com 
Yahoo! Groups Links

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

<*> To unsubscribe from this group, send an email to:
     [email protected]

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