[Chandler-dev] Reviving the DESKTOP Test Automation
Phillip J. Eby
pje at telecommunity.com
Wed Sep 5 22:20:35 PDT 2007
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.)
More information about the chandler-dev