[Webkit-unassigned] [Bug 30997] [Gtk] Implement AtkDocument's attribute support

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30997





--- Comment #8 from Joanmarie Diggs <joanmarie.diggs at gmail.com>  2009-11-02 07:51:15 PDT ---
Now I'm looking at the Unit Tests, in particular testatk.c, because in bug
30964 comment #7, Xan says:

> > I think we should start writing layout tests for these. Would that be possible
> > today or there's a plan to write layout tests for these changes soon?
> 
> Mmm, do you mean unit tests here? Or how could we test ATK APIs from layout
> tests in JavaScript?

And in bug 30964 comment #9, he says:

> OK. Since most of what we are doing here is implementing the ATK APIs I assumed
> you were referring to that. In any case, testing that all those APIs work as
> expected is, at least, as important as doing layout tests for any core AX
> functionality we are using or adding.

I aim to please and to prevent regressions. :-) Questions:

1. (Carried over from previous questions) The only way I could think to test
the new functionality in a layout test was to make an Atk call. So that's what
I did. Is that what I should have done?

2. If it is what I should have done, I believe that tests the relevant Atk
APIs. In which case, what additional/different tests should go in a unit test
for the new functionality?

3. testatk.c seems to me to be a great place to ... oh, I dunno.... test atk.
:-) :-) :-) Given that the new functionality is (at least at the moment) Atk
specific, the layout test I created needed stub functions for Windows and Mac.
And it needed new entries for those two platforms to skip this new,
irrelevant-to-them test. Would it be better to not do a layout test in this
particular case and instead update testatk.c?

Please advise. Thanks!

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.