[Accessibility] Re: [Accessibility-atspi] Re: a11y API/ABI Testing

[David Bolter]

George Kraft wrote:
> On Thu, 2007-11-15 at 10:45 -0500, David Bolter wrote:
>   
>> George, I was thinking we might break out different sections but want 
>> your expert opinion. I was thinking we could separate by the 'layer'
>> or 'layers' that are tested. From API/ABI conformance to.... I'm not
>> sure how far we go?  (Should dogtail and ldtp tools get mentioned here
>> do you think?) 
>>     
>
> For ATK accessibility testing I would create three categories:
> Interfaces, Objects, and Attributes.
>
> http://library.gnome.org/devel/atk/unstable/
>
> http://live.gnome.org/GAP/AtkGuide#head-4c296383976640eb4e340654ce9f2ef9f3b27721
>
> In addition to Dogtail and LDTP,  then you should mention Accerciser and
> Macaroon.
>
> http://live.gnome.org/Accerciser
>
> http://live.gnome.org/Orca/RegressionTesting#head-b1343702005feb50abc4a722c51e38f9a324a676
>
>   
Thanks again.

I agree Accerciser and Macaroon should be noted if we are to mention 
Dogtail and LDTP, but I'm not sure we want to mention any of them on the 
wiki page in question. It depends on our scope. I've done a little 
research and thought about what you said on the call and I think your 
approach of testing via mock application with custom objects at one end, 
atk/gail/atspi in the middle, and mock AT at the other is reasonable 
(what I mean by testing across 'layers'). Do you still agree with this 
approach or has it hit any snags? Do you see advantages to swapping the 
existing mock AT with other similar tools?

Where are the tests run?  Is there a cron job somewhere that checks out 
of gnome svn, builds, runs, and reports?

If migration from the at-spi-registryd daemon approach to a dbus 
implementation happens, we can hopefully catch a lot of problems but 
sticking it between our mock apps and mock ATs which will be very handy 
of course.

Maybe my question is really: is there anything left to do?  Perhaps just 
community building and evangelism?

cheers,
David