[Accessibility] Re: [Accessibility-atspi] Re: a11y API/ABI Testing
david.bolter at utoronto.ca
Fri Nov 16 09:39:14 PST 2007
George, thanks very much for your excellent answers and points.
This is starting to sound like a Mozilla proposal. We just need to
figure out who best can do the work.
George Kraft wrote:
> On Thu, 2007-11-15 at 21:46 -0500, David Bolter wrote:
>> 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?
> I think it is a mixture of straight API testing (221/222) and API
> testing using mock ATs (9/222). The questions are:
> 1) are the 221 new straight API tests acceptable?
> 2) are the 9 prototyped mock AT tests acceptable?
>> Where are the tests run? Is there a cron job somewhere that checks out
>> of gnome svn, builds, runs, and reports?
> I don't know of any build/test systems running these tests, nor any
> posted results.
>> 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?
> Evaluate the above mentioned ATK tests and build a consensus of
> confidence in them. Fix the ATK bugs found by the LSB's new ATK tests.
> Perhaps start working on an AT-SPI test suite that would definitely use
> mock AT tests... This would require a spec review for sufficient
More information about the Accessibility