|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> wrote:
> Did you do this with Hopido? What parts could you test?
Interactive graphical programs are quite a lot harder to test automatically
than libraries which take some input and produce some well-defined output as
a result.
With a library (like a function parser) automatic testing is relatively
easy: The testing program simply uses the library, feeds it some input and
checks what the library returns to see if it's correct (or, in the case of
the function parser, within acceptable limits, as we are talking about
floating point numbers after all, so bit-by-bit equivalence between what
the compiler produces and what the library calculates cannot be expected).
With an interactive graphical program such automatic testing is not that
easy. You can't simply write a program which calls some functions and checks
what those functions return. You would have to programmatically emulate user
interaction, and somehow check that the program does the right thing.
There's a million things which could theoretically go wrong, and most of
them are things which are very hard if not impossible to check
programmatically (eg. visual glitches, wrong timings, etc.)
There's also the question of deadlines. Writing a fully automated test
for an interactive graphical program could at worst take even more time
than implementing the program itself, and that's often just not an option,
especially in a commercial project. The cost-benefit of such testing scheme
would be dubious.
--
- Warp
Post a reply to this message
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> With an interactive graphical program such automatic testing is not that
> easy. You can't simply write a program which calls some functions and checks
> what those functions return. You would have to programmatically emulate user
> interaction, and somehow check that the program does the right thing.
> There's a million things which could theoretically go wrong, and most of
> them are things which are very hard if not impossible to check
> programmatically (eg. visual glitches, wrong timings, etc.)
I suppose you could throw a bunch of user events at it and check that it
doesn't fail any asserts. Doesn't prove it's working right, but it's a
start.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
Orchid XP v8 wrote:
> I suppose you could throw a bunch of user events at it and check that it
> doesn't fail any asserts. Doesn't prove it's working right, but it's a
> start.
Yeah. Lots of the "bugs" I find are things just not following the specs.
It's hard to know in advance (for example) if some randomly mal-formed web
page will "look wrong" when you try to render it, or even what to do about it.
Testing doesn't tell you if your requirements are incomplete or incorrect,
which is I think the primary place my bugs come from.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
![](/i/fill.gif) |