public inbox for mauve-discuss@sourceware.org
 help / color / mirror / Atom feed
From: David Herron <David.Herron@Sun.COM>
To: Thomas Fitzsimmons <fitzsim@redhat.com>
Cc: "Steve McKay☄" <smckay@google.com>, mauve-discuss@sources.redhat.com
Subject: Re: Tweaking default java.awt.Robot settings
Date: Tue, 25 Sep 2007 19:24:00 -0000	[thread overview]
Message-ID: <46F960FC.2070608@sun.com> (raw)
In-Reply-To: <46F95466.7070700@redhat.com>

Thomas Fitzsimmons wrote:
> David Herron wrote:
>> Steve McKay☄ wrote:
>
>> Robot does not add events to EventQueue but it requests the OS to 
>> synthesize an OS-level event.
>
> How has Sun implemented GUI testing?  When I was considering how to do 
> GUI testing in Mauve, I considered the EventQueue-posting approach, 
> but decided on a Robot-based approach instead.  I thought Robot tests 
> would be more realistic, testing things like window manager 
> interactions and the native peers' event processing code.  I knew 
> Robot tests would be more fragile, but I assumed that we could 
> compensate for the fragility: e.g. fix timing problems by introducing 
> delays, as Steve has proposed.  Did Sun experiment with Robot tests, 
> then abandon them?  If Robot can't be counted on to do something 
> within some time delay, is it also useless in non-test applications?
>
> I've always wondered how the TCK certified AWT and Swing 
> functionality.  Does it use EventQueue-posting?
>
> Tom
>


We make heavy use of Robot.

I haven't been writing tests for a long time so I don't know for sure 
the techniques used by the team.  Sometimes I worry about whether they 
are using sleep's and the like to synchronize validation that a desired 
event has occurred.

If you click on something, move a mouse pointer, type a key.. there's a 
listener fired in 99% of the cases you would be testing.  So I think 
it'd be more reliable to synchronize the validation based on when the 
listener fires.  Unfortunately that can turn into difficult coding to 
ensure the test doesn't deadlock or otherwise go off into the weeds 
because cross-thread notification of the listener firing didn't happen 
in the right order.  I'm sure it's much simpler to code up a simple 
sleep and 99% of the time the system will be fast enough responding to 
post the listener callback within a couple milliseconds.

I believe that the TCK, where it has automated tests, uses Robot as 
well.  I don't know that for sure since I've not been involved with 
writing the TCK's, and that's a different team than mine.  The TCK also 
has manual tests.

And the reason you give for using Robot is exactly the reasoning we 
have.  Since we're testing AWT/Swing a we have to make sure to test AWT 
and the peers.  Stuffing events in the EventQueue doesn't test the 
native parts of AWT including the peers.  That was the rationale for 
putting Robot into the platform in the first place (that and to support 
writing freestanding demo apps), and it's true today.

- David Herron



P.S. there's a summary here:
    http://wiki.java.net/bin/view/Javapedia/TestingGUIApplications
of GUI testing methods.. it's been added to over several years and has 
some good pointers.

  parent reply	other threads:[~2007-09-25 19:24 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-24 20:31 Steve McKay☄
2007-09-24 20:50 ` David Herron
2007-09-24 21:22   ` Steve McKay☄
2007-09-24 21:41     ` David Herron
2007-09-25 18:33       ` Lillian Angel
2007-09-25 19:13         ` Steve McKay☄
2007-09-25 19:27           ` Lillian Angel
2007-09-25 19:37             ` Steve McKay☄
2007-09-25 19:45               ` Lillian Angel
2007-09-25 19:27         ` David Herron
2007-09-25 18:33   ` Thomas Fitzsimmons
2007-09-25 18:57     ` Steve McKay☄
2007-09-25 19:58       ` Thomas Fitzsimmons
2007-09-25 20:28         ` Steve McKay☄
2007-10-04  0:43           ` Steve McKay☄
2007-10-04 13:04             ` Lillian Angel
2007-09-25 19:24     ` David Herron [this message]
2007-09-25 18:10 ` Thomas Fitzsimmons
2007-09-25 18:14   ` Steve McKay☄

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=46F960FC.2070608@sun.com \
    --to=david.herron@sun.com \
    --cc=fitzsim@redhat.com \
    --cc=mauve-discuss@sources.redhat.com \
    --cc=smckay@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).