[TIP] Functional Testing of Desktop Applications

Grig Gheorghiu grig at gheorghiu.net
Sun Mar 4 15:54:44 PST 2007

--- Michael Foord <fuzzyman at voidspace.org.uk> wrote:

> Grig Gheorghiu wrote:
> > --- Vladimir Ignatov <kmisoft at gmail.com> wrote:
> >
> >   
> >> BTW I am still unsure what unittesting GUI part is a good idea.
> >>
> >>     
> >
> > I think this is an excellent point. In my experience, testing at
> the
> > GUI level is very prone to breakages, especially if you have a lot
> of
> > assumptions that might prove to be invalid once your GUI layout
> > changes. 
> Hmmm...it's not been more subject to breakage that other API changes
> in 
> my experience.
> With Windows Forms perhaps it is a bit easier: you can give GUI 
> components (controls) 'names' (a Name attribute that serves no
> purpose 
> other than to identify the control). You can then recursively iterate
> through controls (child controls are stored in the 'Controls'
> collection 
> of container controls) looking for them by name. This reduces
> breakages 
> due to minor layout changes - we have a 'getControlByName' method on
> our 
> test framework.
> We do still have to change the parent control we start the search
> from 
> occasionally when our layout changes.

You're right, if you name your controls, you have a better chance of
having tests that don't break as easily. This is also a useful
technique when testing a Web application -- set the ID field of the
different HTML elements you want to test.

> > The strategy I recommend is to have a shallow set of GUI testing,
> just
> > for smoke testing purposes, and put most of the functional testing
> at
> > the application logic level, below the GUI. This will also force a
> > cleaner design of the application (MVC etc.)
> >
> >   
> In my opinion, functional tests that operate below the GUI level
> aren't 
> proper functional tests. Functional tests (as much as possible)
> interact 
> with your application in the same way as the user. This is *not* an 
> impossible goal - and will test things that can't be tested in other
> ways.

Well, people have different names for different types of tests. What
you call functional tests, other people call system/integration tests.

The way I see it, it's not the names that are important, but the
different types of testing that need to be done at different levels:

* at the unit level (unit testing)
* at the application logic level below the GUI (functional, or
integration, however you want to call it; the idea is that you exercise
a path through several units of your code) 
* at the GUI level. 

It's hard to achieve a good test coverage at the application logic
level below the GUI, but it's well worth it IMO. As I said, it forces
you into a cleaner application design.


More information about the testing-in-python mailing list