Home > Archive > Software Testing > May 2005 > Test tool for event driven windows application
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Test tool for event driven windows application
|
|
| Gerard 2005-05-02, 4:02 am |
| Hi,
Got a big event driven windows application. Events are created by hardware
and by users. The GUI is the most critical part of the application
(enabled/disabled controls, etc.). What would be the best tool to automate
testing of such an application?
TIA,
Gerard
| |
|
| Gerard wrote:
> Got a big event driven windows application. Events are created by hardware
> and by users. The GUI is the most critical part of the application
> (enabled/disabled controls, etc.). What would be the best tool to automate
> testing of such an application?
A technique called variously Logical User Interface, Representation Layer,
Presentation Layer, or Humble Dialog Box.
http://www.objectmentor.com/resourc...leDialogBox.pdf
Write a module that does everything your GUI does, but uses no GUI controls
whatsoever. Anything a user can do to the GUI, a programmer can do to the
module. If a user can click Submit, you have a Submit() button. If they can
click on an element in a list box, you can pull a List of objects and pass
one into a responding function.
Anything the GUI can do to a user, this module does to programmers. If the
GUI would disable that list box, then the programmer can detect the
disability. If the GUI can refresh its display automatically when new data
appears, the module can send a message using the Observer Design Pattern.
Now write the actual GUI, and make certain every function is as short as
possible. It should do nothing but instantly delegate to the equivalent
functionality in this wrapper module.
Now write automated tests that beat the snot out of this wrapper module.
--
Phlip
[url]http://www.c2.com/cgi/wiki?Z Land[/url]
| |
| Gerard 2005-05-02, 9:00 am |
| Hi,
Nice answer, but we did program already and did separate GUI from business
rules and classes. The GUI is (quite) complicated so we need to test it and
not the business rules (UnitTest etc. already done).
Writing new code to test will be a lot of effort and results in disputes
whether the test is right or the original is wrong.
Any experience with:
QaRun,
WinRunner
AutomatedQA
???
TIA,
Gerard
"Phlip" <phlip_cpp@yahoo.com> wrote in message
news:Wojde.947$Yg4.485@newssvr17.news.prodigy.com...
> Gerard wrote:
>
>
> A technique called variously Logical User Interface, Representation Layer,
> Presentation Layer, or Humble Dialog Box.
>
> http://www.objectmentor.com/resourc...leDialogBox.pdf
>
> Write a module that does everything your GUI does, but uses no GUI
> controls
> whatsoever. Anything a user can do to the GUI, a programmer can do to the
> module. If a user can click Submit, you have a Submit() button. If they
> can
> click on an element in a list box, you can pull a List of objects and pass
> one into a responding function.
>
> Anything the GUI can do to a user, this module does to programmers. If the
> GUI would disable that list box, then the programmer can detect the
> disability. If the GUI can refresh its display automatically when new data
> appears, the module can send a message using the Observer Design Pattern.
>
> Now write the actual GUI, and make certain every function is as short as
> possible. It should do nothing but instantly delegate to the equivalent
> functionality in this wrapper module.
>
> Now write automated tests that beat the snot out of this wrapper module.
>
> --
> Phlip
> [url]http://www.c2.com/cgi/wiki?ZLand[/url]
>
>
| |
|
| Gerard wrote:
> Nice answer, but we did program already and did separate GUI from business
> rules and classes. The GUI is (quite) complicated so we need to test it
and
> not the business rules (UnitTest etc. already done).
We are discussing 3 layers here - the GUI Layer (should be thin), the
Representation Layer, and the Logic Layer. You are confessing the GUI and
Representation Layers are coupled. Decouple.
> Writing new code to test will be a lot of effort and results in disputes
> whether the test is right or the original is wrong.
Any retrofitted tests will. The disputes are called "progress". Whoever has
an opinion about test veracity should directly collaborate to write the
tests.
> Any experience with:
>
> QaRun,
> WinRunner
> AutomatedQA
> ???
Others will point out how to use them. You don't need them because your GUI
most likely uses the most common architecture for desktops. Between creating
and displaying a window you can send data to controls, and fire their
events. So, write test cases directly to the GUI Layer.
Those tools are to make bosses think people who can't program can test.
--
Phlip
[url]http://www.c2.com/cgi/wiki?ZLand[/url]
|
|
|
|
|