UI software testing

Nickolay Belofastow

unread,

Jun 15, 2002, 4:19:30 PM6/15/02

to

Hi,

XP assumes regression testing, it is possible only if you do automated
testing using Jtest, for instance.

My question is: how to test user interface software? I have trouble to
imagine automated tests for graphic user interface software, because someone
should check the visual appearance.

Do you know some test tools for such situations? How to apply XP here?

Regards, Nickolay

John Roth

unread,

Jun 15, 2002, 5:45:21 PM6/15/02

to

"Nickolay Belofastow" <Nickolay....@ieee.org> wrote in message
news:aeg6vj$ik8$1...@nntp-m01.news.aol.com...

There isn't a good, cheap solution. The best availible solution is to
partition the problem by putting as much of the actual functionality
into modules that can be tested automatically, and leave a very
minimal, thin UI module that has to be tested manually, but will be
very stable because it's very small and has the absolute minimum
functionality.

Your typical event handler should be a simple call to another
function (or method) in another module (or class). Then you
can test that module/class to your heart's content.

John Roth
>
>

Ron Jeffries

unread,

Jun 15, 2002, 7:59:27 PM6/15/02

to

Short answers. Thin GUIs. Test against the structures that drive the GUIs. Look
at the screen once, see if it is OK. Screen capture it, thereafter compare
against the capture. When it doesn't agree, reverify.

HTH,

Ronald E Jeffries
http://www.XProgramming.com
http://www.objectmentor.com
I'm giving the best advice I have. You get to decide whether it's true for you.

marc beaudry

unread,

Jun 17, 2002, 11:52:48 AM6/17/02

to

Hi,

I agree with both John and Ron, that is thin GUIs. And in addition, if you
are using Java, you can try "jfcunit". It resembles JUnit but adds
functionality for testing different GUI components. I've done some minor
experiments with it so far and it's doing the job.

Good luck,

Marc

"Ron Jeffries" <ronje...@REMOVEacm.org> wrote in message
news:k4lngu0iap271jraq...@4ax.com...

Robert C. Martin

unread,

Jun 17, 2002, 4:23:48 PM6/17/02

to

On Sat, 15 Jun 2002 22:19:30 +0200, "Nickolay Belofastow"
<Nickolay....@ieee.org> wrote:

Checking the visual appearance is only one very small part of GUI
testing; and it is the only part that doesn't yeild to Junit testing.
Everything else can be tested automatically without any additional
tools of effort.

For the visual appearance, it is possible to buy tools like WinRunner,
but I don't recommend this unless you are planning on shipping
hundreds of thousands of shrink-wraps. Visual inspection of the
appearance is probably adequate, and can be done at strategic moments
during the release.

Everything else can be tested automatically. The strategy is actually
quite simple, though some find it counter-intuitive. It works like
this:

1. You put the GUI code into a module called the View. You keep the
View very thin. You don't want *any* intelligence inside it. Rather
you put this very thin View behind an interface and control it from a
non-GUI module called the "Presenter".

2. The Presenter does not make any GUI calls. It controls the GUI
through the View. If it wants an item in a listbox to be selected, it
calls the appropriate method on the view. If it wants to grey out a
button, it calls the appropriate method of the View. The Presenter
manages all the intelligence of the GUI, without actually knowing
anything about the GUI API. The View presents an abstraction of the
GUI that the Presenter can manipulate.

3. You write tests for the Presenter. This is trivial since the
Presenter is a pure computational module.

4. The tests you write for the View do not check the way the GUI
looks. Rather they test the "wiring" of the GUI. For example, the
tests check to see that the main window contains a set of radio
buttons. It tests to see that the radio buttons are named correctly.
It tests that each group of radio buttons shows mutually exclusive
behavior. It mimics mouse and keyboard events and tests that the
correct callback functions are called (using a MockObject interface or
a Self Shunt.)

That's it. The only thing remaining is to actually look at the screen
and play with the interface. And that can be done at the end of the
iteration.

You and I can enjoy the experience of not always seeing
eye-to-eye, but we can also respect each other, even when
you might find some idea of mine totally ludicrous.
-- Richard Riehle

Henrik Schlanbusch

unread,

Jun 19, 2002, 1:08:23 AM6/19/02

to

Hi. In the adaptit project, we use NetBeans' "jemmy" module to do our GUI
tests. The module is really easy to use, and has powerful functions, among
others it can capture the screen during the GUI test. We use the module both
to the GUI tests, but in addition to write our help manuals. For every new
function in the system we write a GUI test. Along with the test, we write
the text that should be included in the help system for a step - by - step
instruction on how to perform the function. If needed screenshots are
included in the help text. This way we have a large set of GUI tests that
test the functions that the users will use. If the GUI test breaks because
of changes in the GUI, we know that the helptext is out of synch as well,
and thus we update both the help text and the GUI test accordingly to fit
the new solutions to the GUI.

Regards,

Henrik Schlanbusch

Nickolay Belofastow <Nickolay....@ieee.org> wrote in message
news:aeg6vj$ik8$1...@nntp-m01.news.aol.com...

Kent Beck

unread,

Jun 19, 2002, 1:55:46 AM6/19/02

to

Henrik Schlanbusch <henrik.sc...@intermedia.uib.no> wrote in message
news:aep3kb$1cj0$1...@toralf.uib.no...

> Hi. In the adaptit project, we use NetBeans' "jemmy" module to do our GUI
> tests. The module is really easy to use, and has powerful functions, among
> others it can capture the screen during the GUI test. We use the module
both
> to the GUI tests, but in addition to write our help manuals. For every new
> function in the system we write a GUI test. Along with the test, we write
> the text that should be included in the help system for a step - by - step
> instruction on how to perform the function. If needed screenshots are
> included in the help text. This way we have a large set of GUI tests that
> test the functions that the users will use. If the GUI test breaks because
> of changes in the GUI, we know that the helptext is out of synch as well,
> and thus we update both the help text and the GUI test accordingly to fit
> the new solutions to the GUI.

Can you post an example script? Also, have you ever written these scripts in
advance of implementation?

Kent

Henrik Schlanbusch

unread,

Jun 19, 2002, 8:15:37 AM6/19/02

to

Find attached an example written in advance of implementation:

The code snipplet makes a test for opening a diagram, adding an element (a
taskclass) in the diagram by using the popup menu, and then opening a sub
diagram from the recently added taskclass in the diagram. The test specifies
exactly the path to go, which makes it extreme handy for writing help text
in addition to being a normal GUI test.

The user has specified how he wants to navigate in the application in
discussion with the programmer. When they have agreed, the programmer goes
back into office, and creates a test that walks through the path the user
required. Then, the programmer simply sits down and programs. Integrated in
the test, the programmer adds the help text. Simple, eh?

The GUI tests are part of our continious integration, and we get a report
after each build, which happens 4-5 times a day. This way we can discover
fast if GUI has been changed, and help systems has to be updated
accordingly.

As the API has matured, the tests have become more easy to write in advance.
We hope to completely integrate the GUI test writing in advance of/during
each iteration for all userstories, and thus continious sequring that the
system runs, and that it has a completely updated helpsystem.

-Henrik

public int test(Object param) {
try {
bluePrintOperator = TestHandler.getTestHandler().getBluePrint();
BluePrintDiagram bluePrintDiagram = (BluePrintDiagram)
bluePrintOperator.getSource();
bluePrintOperator.clickForPopup();
if(bluePrintOperator != null) {
Thread.sleep(1500);
setTutorialHeading("How to open the exploded blueprint
view");
addTutorialElement("Open the blueprint by clicking the tab
labeled 'blueprint'");
addTutorialImageForComponent(bluePrintDiagram,
"BluePrintDiagram");
JMenuItemOperator addTaskClassItem = new
JMenuItemOperator(TestHandler.getTestHandler().getApplicationFrame(), "Add
Task Class");
if(addTaskClassItem != null) {
addTaskClassItem.doClick();
Thread.sleep(1500);

addTutorialElement("Add a taskclass, select it and
choose to open task class");
Node taskClassNode =
TestHandler.getTestHandler().getNode("TaskClass", bluePrintDiagram);
if(taskClassNode == null) {
GUITestLogger.getGUITestLogger().logFailure("Could
not locate the node taskclass");
return 1;
} else {

TestHandler.getTestHandler().showPopupForNode(taskClassNode,
bluePrintOperator);
JMenuItemOperator openExplodedBluePrintViewItem =
new JMenuItemOperator(TestHandler.getTestHandler().getApplicationFrame(),
"Open Task Class");

addTutorialImageForComponent(openExplodedBluePrintViewItem.getSource(),
"item");
openExplodedBluePrintViewItem.doClick();
Thread.sleep(2000);
}
} else {
GUITestLogger.getGUITestLogger().logFailure("Could not
locate the add taskclass item in popup");
return 1;
}

} else {
return 0;
}
"Kent Beck" <kent...@my-deja.com> wrote in message
news:aep6ll$3ik$1...@nntp-m01.news.aol.com...