Interacting with an application under test (AUT) is only half of the story. In order to verify facts about the AUT, WindowTester Pro provides a rich assertion story.

  1. Asserting Conditions
  2. Common Widget Property Conditions
  3. Assertion Factories
  4. Ensuring Condtions
    1. Example: Welcome Page Handling
  5. Manual Assertions
    1. Refactoring to a Condition
  6. Related Resources

Asserting Conditions

Conditions specify properties to assert. For instance, to assert that a Shell with text “Input Dialog” is active, one would write:

ui.assertThat(new ShellShowingCondition("Input Dialog"));

The WindowTester Pro runtime offers a number of useful conditions for building assertions.

Common Widget Property Conditions

WindowTester Pro provides a convenient way to test whether a particular UI component is enabled using IsEnabledCondition. Any locator that implements the IsEnabled interface may be used with the IsEnabledCondition to determine whether a UI component is enabled. In addition, any locator that implements HasText can be used withHasTextCondition to determinewhether a UI component has specific text. Similarly, IsSelected can be used with IsSelectedCondition to test whether a given widget is selected.

For example, if you wanted to assert that the Finish button was enabled or that the Wizard had a particular error message...

ui.assertThat(new IsEnabledCondition(new ButtonLocator("Finished"), true)); 
ui.assertThat(new HasTextCondition(new WizardErrorMessageLocator(), "some wizard message"));

... or ...

ui.assertThat("Finish button should be enabled", new IsEnabledCondition(new ButtonLocator("Finished"), true));
ui.assertThat("The error message is wrong", new HasTextCondition(new WizardErrorMessageLocator(), "some wizard message"));

In fact, any Condition can be used in the test to assert that the application is in a valid state.

Assertion Factories

For convenience, some locators provide factory methods that return appropriate condition instances for use in building assertions.

For example, the above condition can be simplified like so:

ui.assertThat(new ButtonLocator("Finished").isEnabled());
ui.assertThat(new WizardErrorMessageLocator().hasText("some wizard message"));

For more on condition factories see this document. The javadocs for the locators also document the condition factories they support.

Ensuring Condtions

Some conditions can be used to ensure that certain properties are true. Such conditions implement the com.windowtester.runtime.condition.IConditionHandler interface and are passed in to the IUIContext.ensureThat(..) method.

Example: Welcome Page Handling

In RCP application testing it is often convenient to ensure that the Eclipse “Welcome” screen has been dismissed before proceeding with a test. (Not dismissing this screen might cause the test to fail in case the test seeks to interact with widgets that are behind the Welcome.) To handle this problem, the following idiom was adopted by many RCP testers1.

protected void closeWelcomePageIfNecessary() throws Exception {
   	IWidgetLocator[] welcomeTab = getUI().findAll(new CTabItemLocator("Welcome"));
	if (welcomeTab.length == 0)

This method was in turn called in the setUp() method of a common test base class like so:

public class BaseTest extends UITestCaseSWT {
	protected void setUp() throws Exception {

Condition handlers improve this story. Using the view.isClosed() condition handler, the logic is simplified to this:

public class BaseTest extends UITestCaseSWT {
	protected void setUp() throws Exception {

Manual Assertions

If there is not a condition that is sufficient out-of-the-box, you can write assertions manually but care needs to be taken. Tests execute on a different thread from the user interface, so you must wrap your calls to component accessors in in a runnable and pass it to the display to be executed on the user interface thread. The accessors and conditions listed above handle those details for you automatically, but if you want to write other types of assertions they must be wrapped to safely access component information.Accessing a component in the test thread rather than the UI thread causes an SWTException to be thrown. For example this hypothetical test case tests a drag and drop operation on a tree:

//select a tree item  
ui.click(new TreeItemLocator("treeItem2"));
//drag and drop it on another
ui.dragTo(new XYLocator(new TreeItemLocator("treeItem2"), 5, 5));
//perform assertions safely on the UI thread
Display.getDefault().syncExec( new Runnable() {
	 public void run() {         
		//get the tree widget
		Tree tree = (Tree)((IWidgetReference)ui.find(new SWTWidgetLocator(Tree.class))).getWidget();
		//the first item in the tree should now have the EXPECTED label
		TestCase.assertEquals(EXPECTED_LABEL, tree.getItems()[0].getText());