Wed, 22 Feb 2006
Table of contents for the "GUI testing tarpit" series
My "working your way out of the GUI testing tarpit" series really
ought to be put into a single paper with the rough transitions
smoothed over. Until that happens, if ever, what I've got will have to
serve. Here's the table of contents.
Three
ways of writing the same test: click-specific procedural,
abstracted procedural, and declarative. The first two are
usually inefficient solutions to their problems. Life is better
if you get rid of as many procedural tests as possible. That's
what this series is about.
A
declarative test might require a lot of test-specific work
behind the scenes. To avoid that, build an engine that can deduce
paths through the app.
Trying to convert a whole test suite at once is
failure-prone. Therefore,
convert
the suite one failure at a time.
Capturing abstract UI actions behind the scenes doesn't provide
much speedup, but it allows a dandy programming, debugging, and
testing tool that lets you
get
to any page
in one step.
If you have your tests avoid the network, you'll discover that
many tests boil down into assertions about the structure and
contents of a single page. There's no reason those can't be
fast, targeted, robust unit tests.
But if most tests are about single pages, how do you prevent
changes from introducing dead links? The renderer can
check
links without clicking on them, at unit-test time.
Not everything can be turned into a fast, network-avoiding unit
test.
Workflow
tests remain GUI tests, but they should clearly focus on
workflow and not test things better tested elsewhere. Such
tests can be an integral part of the design of
application flow.
## Posted at 09:35 in category /testing
[permalink]
[top]
|
|
