[Chandler-dev] Reviving the DESKTOP Test Automation Project

[Phillip J. Eby]

At 08:55 PM 9/5/2007 -0700, Aparna Kadakia wrote:
>It is important to remember that the framework we adopt needs to 
>support testing at the UI level and not within. This is more for 
>functional testing which covers scenarios rather than unit level testing.

Crossing over a thread here, I think it's important to point out that 
"UI level" in this context presupposes an architecture in which there 
*is* such a thing.

One possible architecture refactoring is to have an "interaction 
model" layer which encompasses a significant portion of what would 
now be considered "UI level" code -- but *without* having any "UI" 
code (i.e., graphics or I/O).  Such a system would be amenable to 
automated functional testing without involving any actual GUI 
code.  (See also my reply to John's post about transparent 
persistence; this is the same visual/logical split I described there.)

In addition, it would eliminate the issue we've had with the 
functional test frameworks that are distinct from the application 
itself.  In an interaction-model design, the application *is* the 
functional test framework, so there is no duplication of 
functionality, documentation, learning, code getting out of sync, etc.

Of course, that approach won't catch graphical glitches and 
platform-specific wx behavioral quirks, but if I understand 
correctly, we don't have a way to catch them in an automated fashion 
now, do we?  (When I run functional tests and the screen sometimes 
does funky things, it doesn't seem to cause any test failures.)