[TIP] Functional Testing of Desktop Applications
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
> > GUI level is very prone to breakages, especially if you have a lot
> > 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
> my experience.
> With Windows Forms perhaps it is a bit easier: you can give GUI
> components (controls) 'names' (a Name attribute that serves no
> other than to identify the control). You can then recursively iterate
> through controls (child controls are stored in the 'Controls'
> of container controls) looking for them by name. This reduces
> due to minor layout changes - we have a 'getControlByName' method on
> test framework.
> We do still have to change the parent control we start the search
> 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,
> > for smoke testing purposes, and put most of the functional testing
> > 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
> proper functional tests. Functional tests (as much as possible)
> 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
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