Testing UI with WindowTester

For UI-driven automated testing, we are using Instantiations' WindowTester to record UI interactions as Java JUnit tests.

Many thanks to Instantiations for the license for use on the m2eclipse project! Project developers should contact the m2eclipse project lead for the license to use for m2eclipse testing.

To record and generate UI tests,

Have Eclipse with PDE features (e.g. Europa or Ganymede bundles Eclipse Classic or Eclipse for SWT/RCP Developers)
Install WindowTester from Instantiations.
Check out their excellent documentation!

The generated tests (and any you add) may need the following plug-in dependencies:

com.windowtester.runtime,
com.windowtester.swt.runtime,
com.windowtester.swing.runtime,
com.instantiations.eclipse.debug,
com.instantiations.common.core,
com.instantiations.eclipse.util,

To compile and run the Java JUnit tests, update the target platform with the WindowTester runtime, e.g.,

<target name="m2e e34">
  ..
  <content useAllPlugins="true">
    ...
    <extraLocations>
      ...
      <location path="C:\eclipse\eclipse.windowtest_3.5\Shared_v5.3.2.200806270030\E-3.4\eclipse"/>
      <location path="C:\eclipse\eclipse.windowtest_3.5\WindowTester_v3.5.0.200806270034\E-3.4\eclipse"/>
      ...

For a sample test, see PomEditorTest in org.maven.ide.eclipse.editor.tests. This test targets the Maven POM editor and verifies that artifact id changes made in xml source are reflected in the Overview form.

The test steps are:

Start from fresh workspace...
Close any "Welcome" page
Create new Maven project using simple Maven project wizard
Open pom.xml
Switch to pom.xml tab in the POM editor
Replace "test-pom" artifactId with "test-pom1" using Find/Replace dialog
Switch back to the "Overview" tab
Verify "Artifact Id" field been changed to "test-pom1"

That's the level of steps to consider. To make things easier for you and to make the tests more robust to UI changes and runtime interference, here are a few tips:

Most tests require some setup. It's useful to try doing so with the UI, but if that's too slow or unstable, consider using code instead.
- Use WindowTester to open "New Maven project" wizard and go trough wizard UI, or
- In the test code, use Eclipse or m2eclipse APIs. For examples, see JUnit tests in org.maven.ide.eclipse.tests.

Avoid potential interference. E.g., when starting, Eclipse may open the "Welcome" page, so the test should close it before starting. (This page may or may not need to be closed, so there is some logic still missing in the test to verify if page is open.)

Avoid depending on workbench UI that differs by platform. For example:
- Different keyboard shortcuts and different menu locations for the same actions (especially on OSX). Eg. on OSX there is no Ctrl-M and content of the "Window" menu is in different place Perhaps some conditions or helper classes need to be used for that
- Different screen size. If window is too small, and won't have enough space for all view, editor or internal editor tabs. You will see "chevron" menu on the right that will have popup menu; regular "tab clicking" won't work for tabs moved to that menu. Possible workaround could be to maximize editor. (Using ctrl-M shortcut, or from main menu "Window/Navigation/Maximize Active View or Editor", may be platform dependent.)

i10n version of the product won't work with English UI recording. We would need to manually internationalize test code, avoid specifying names, or using the i10n variants.

WindowTester is great but in some cases it may record not what is intended, so you may need to edit the generated test code. See, for example, the following FAQ entries.

While UI test is running, don't change the UI or the current focus, e.g., by working in another UI application. Though you could run UI tests in its own virtual machine, e.g. in VMWare.

Avoid mouse- or keyboard-driven interactions as brittle. Naive recording, e.g., in the plain text or xml editor UI can produce code that is hard to maintain (lots of "down", "down", "down" key clicks to position to some text). Find more robust workarounds like using "Find/Replace" dialog (or maybe even locate text editor SWT widget used by Editor and manipilate text trough its API). The latter may not work in some advanced editors that have their own way to change edited text.

WindowTester uses various widget locators to find things in the UI. Sometimes we will need to assign names to widgets so the test code can pick them out by name using calls like control.setData("name", <uniqueLocalVariableName>)

You can code any assertions on UI widgets using WindowTester assertion API. See WindowTester Eclipse help and javadocs for more details.

If you have other WindowTester questions, see the WindowTester FAQ

Testing UI with WindowTester

Labels