Re: [g-a-devel]Test harness tool for accessibility - approach..
- From: Bill Haneman <bill haneman sun com>
- To: mukund rajagopalan wipro com
- Cc: gnome-accessibility-devel gnome org
- Subject: Re: [g-a-devel]Test harness tool for accessibility - approach..
- Date: Fri, 08 Mar 2002 15:04:03 +0000
Mukund wrote:
>
...
> The tool will use test_simple.c as the base with the
> difference that instead of creating a test window, query an
> application (using gtk-demo for this purpose will simplify
> automation).
gtk-demo also gives pretty good coverage of the widget
APIs. I suggest that the whole test be embedded in a script
which could specify geometry for the gtk-demo program, etc.
so that even detailed information like screen coordinate
bounds could reasonably be expected to be consistent.
> At the first level, the tool will basically traverse the ATK
> object hierarchy and query the implementation.
>
> At the next level, automate testing by making use of
> key-synth or action. That is, play with the UI components
> (if it's a button, do_action, etc).
Yes, and this has the added benefits of:
(a) aiding automation of the test;
(b) testing the 'active' parts of AT-SPI such as key synthesis
and action invocation.
(Note that Michael has noted some reproducibility issues
with key synthesis which would, presumably, need to be
dealt with before this regression test could be effectively
used).
> Maintain a log of what's happening and make a diff of the
> logs with each run to check for inconsistency. This
> particular step could be as primitive as a diff or as
> sophisticated as a parse-able content (for better report
> generation).
>
> While this approach ensures code-coverage to a very decent
> extent, it also handles across-process testing that covers
> registry, at-spi (cspi, libspi), atk-bridge, atk and gail!
>
> Thoughts ?
In conjunction with the unit tests you've described, which
are also good diagnostic tools for application accessibility
(i.e. an improved ferret, and a gle-like in-process accessibility
tool), it sounds to me that this would make an excellent
base for both specific regression tests (as bugs are found, logged,
and fixed) and for API coverage.
I'd advocate occasionaly "touch-testing" manually with
a pseudo-AT like "simple-at" as well.
-Bill
> Mukund.
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]