Re: [g-a-devel]Test harness tool for accessibility - approach..

[Marc Mulcahy <marc mulcahy sun com>]

This looks good.  When implemented, the test harness may also wish to test 
the mouse event synthesis code in at-spi.

Also, functionality could be added to report the inaccessibility of an 
application (for example, this certain control doesn't have a name, etc.).

Marc

At 08:32 PM 3/8/2002 +0530, Mukund wrote:
> Towards ensuring test harness for accessibility
> architecture, here's some thoughts on what the test-tool
> must do and how it's could be implemented (note that the
> objective here is code-coverage):
>
> 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).
>
> 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).
>
> 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 ?
>
> Mukund.
>
>
> _______________________________________________
> Gnome-accessibility-devel mailing list
> Gnome-accessibility-devel gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-devel