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 –3 rd 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 –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