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.
next prev 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).