Automated UI testing of Swing
based applications
Tomas Krecmer
Barclays
27. February 2012
UI testing

What do we want to test?
– Custom widgets
– Data models
– Business logic

What not?
– Swing
– 3rd party widgets, windowing framework
– Server functions via client

How do we implement the tests?
– Who to implement
– What technology
Testing of existing application






Usually not fine grained – business logic
mixed up with UI code
Server calls from widgets
Controllers polluted by UI updates
Idea not to rewrite anything
Hard to mock up
Missing names of the widgets to identify
them on the screen
Test your application by external program

Test your application by external program
– Simulates user interaction
– Run against dedicated environment needed
– No major changes to application itself (just
add names to widgets)
– Technologies like HP QTP (Mercury), Silk
– Testing scripts written in scripting language
like Visual Basic. Tests can be written by QA
team
– Library to navigate on custom widgets
– Expensive, slow
Unit testing - approaches

Pure unit tests for isolated functionality
(widgets, controllers, models)

For mixed up code - initialize whole
application from Unit test against
reference environment. Testing thread
interacts with UI (through UI thread) and
verifies expected results. No need for
mocking.
Unit test technologies

TestNG – general purpose Unit testing framework
– More advanced than JUnit
– Supported by other technologies (ant, TeamCity,
Eclipse, FEST, JMockit)

FEST – Swing testing framework
–
–
–
–
–
–
Pure Java framework
Simulates user interaction
Heavy support for widget’s look up
Needs to initialize UI ei. must be run on Windows box
Good UI thread management
Other framework under investigation (UISpec4J, Jemmy,
Abbot, jfcUnit)
– Takes screenshot on failure
FEST example
Verify when password not set error dialog is
displayed
DialogFixture dialog = frame.dialog(“login”);
dialog.textBox("username").enterText("alex.ruiz“);
dialog.button("ok").click();
dialog.optionPane().requireErrorMessage()
.requireMessage("Please enter
your .*"); // regular expression matching
Integration with Dev Process
Run as part of Continuous
Integration
 Set up for each DEV branch
 Results are used as a test evidence
for releases
 Dedicated Windows box

Reality
Originally 1200 manual testing
scenarios existed
 Converted to 270 unit tests
 Covers 800 of original scenarios
 Total run 2.5 hours
 Total implementation cost about 120
MDs
 Saved 40MDs per release

The End

Q&A
Links
http://www.barcap.com/
 http://testng.org/doc/index.html
 http://code.google.com/p/fest/
 http://code.google.com/p/jmockit/
