Re: [g-a-devel] Test driven development

[Brian Nitz <brian nitz oracle com>]

I found this tutorial explaining how test driven development (TDD) was 
used for gtk, glib and gdk.

Is TDD still being used in GNOME?  Shouldn't the parts of gtk related to 
accessibility (e.g. what was once the separate GAIL module) have test 
cases in gtk+/atk/tests?


On 23/01/12 14:31, Brian Nitz wrote:
> Sorry I never got back with the details of what I called 
> "test-centered development."
>
> Level 4 of Testing Maturity Model (TMM 
> http://en.wikipedia.org/wiki/Testing_Maturity_Model) requires:
> At this level testing activities take place at all stages of the life 
> cycle, including reviews of requirements and designs. Quality criteria 
> are agreed for all products of an organisation (internal and external).
>
> But some aspects of this focus on early testing (actually called "test 
> driven development or TDD") are also part of extreme programming.  
> Wikipedia explains TDD better than I can:  
> http://en.wikipedia.org/wiki/Test-driven_development#Add_a_test
>
>
> What does this means for accessibility?
>
> Formal TDD may be overly complicated for our needs but the reason I 
> brought it up at an a11y a meeting a few eons ago is that sometimes it 
> feels like GNOME software testing is not being considered early 
> enough.   Sometimes it seems as though testing is being treated as an 
> afterthought and accessibility testing an after-aftertought.   Much of 
> this testing is user-focused which does require an integrated desktop 
> test environment (distro) such as the GNOME accessibility testing 
> distro.  Complete accessibility testing also requires assistive 
> technology as well as a user familiar with that assistive technology.  
> But if we can help application developers test some accessibility 
> features earlier in their development lifecycle, it might help us 
> discover and fix a few accessibility bugs earlier.
>
> The Aegis accessibility testing framework 
> https://live.gnome.org/AegisA11yTesting along with the accessibility 
> test distro (configured as a tinderbox) is intended to facilitate some 
> accessible API testing earlier in the development lifecycle.  But I 
> think it's just as important to remind developers that whenever a 
> feature, component or patch is created, think about how it can be 
> tested for accessibility.