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.)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
