GUI Testing Development

JUnit 4 basics

Here is a short cookbook showing how to use JUnit 4. If you know Java, it's very easy for you to understand it.

Write GUI test case

A simple example

You can find one simple example in the testgui project. The source code is testgui/source/testcase/gui/AOOTest.java.

package testcase.gui;
 
import static org.junit.Assert.*;
import static testlib.gui.AppUtil.*;
import static testlib.gui.UIMap.*;
 
import org.junit.After;
import org.junit.Before;
import org.junit.Rule;
import org.junit.Test;
 
import testlib.gui.CalcUtil;
import testlib.gui.Log;
 
/**
 * If AOO is not installed in the default directory, please specify the system property in your command line. <br/>
 * -Dopenoffice.home="Your OpenOffice installation directory which contains soffice.bin"
 *
 */
public class AOOTest {
 
	/**
	 * Add Log to enable the following capabilities.
	 * 1. Take a screenshot when failure occurs.
	 * 2. Collect extra data when OpenOffice crashes.
	 * 3. Log any detail information.
	 */
	@Rule
	public Log LOG = new Log();
 
 
	/**
	 * Do some setup task before running test
	 * @throws Exception
	 */
	@Before
	public void setUp() throws Exception {
		//Start OpenOffice with a clean user profile
		app.start(true); 
	}
 
	/**
	 * Clean task after testing
	 * @throws Exception
	 */
	@After
	public void tearDown() throws Exception {
 
	}
 
	/**
	 * Implement test steps 
	 */
	@Test
	public void testHello() {
		startcenter.menuItem("File->New->Spreadsheet").select();
		calc.waitForExistence(10, 3);
		typeKeys("Hello");
		assertEquals("Assert", "Hello", CalcUtil.getCellInput("A1"));
	}
 
}

testlib.gui.UIMap

The classes under package org.openoffice.test.vcl.widgets can be used to interact with VCL controls. To construct the classes, GUI control's Help ID should be specified.

VclWindow startcenter = new VclWindow("FWK_HID_BACKINGWINDOW");
startcenter.click();
VclButton someButton = new VclButton("SC_HID_INSWIN_CALC");
someButton.click();
boolean checked = someButton.getText();
VclListBox someListBox = new VclListBox("some.listbox.id");
someListBox.select("Item1");
String selected = someListBox.getSelText();

Generally we define GUI controls centrally in one class named testlib.gui.UIMap. The advantage is that we can easily update our scripts when GUI changes. There have been many pre-defined controls. For example:

• app: The whole AOO application
• startcenter: Startcenter window
• writer: Writer window
• calc: Calc window
• impress: Impress window.

You can define new GUI control by add one line in the class or use one Eclipse plugin named testassistant to simplify the thing.

How to define GUI controls

Use VCL Test Assistant Eclipse Plugin
Install the plugin into your eclipse.
File:Testassistant.zip
Open Eclipse Preferences, find the page "VCL Test Assistant" and then specify OpenOffice installation directory.

Open "VCL Test Assistant->VCL Explorer" view.

Click Launch to start OpenOffice and then click Inspect.
Now, OpenOffice will pops up a floating windows titled "DisplayHID". Drag the gray circle to some controls and then release the button.

Go back to VCL Explorer, you will get the Help IDs.

If you want to use any control, left double click on the "Name" item of the control which you want to use, then add a name to it. Then you will find a UI control defined automatically in the last line of UIMap.java.(%EclipseWorkspaceDir%\test\testscript\src\testlib\UIMap.java). Then you can use the control by name you defined instead of using control ID.

testlib.gui.AppUtil

testlib.gui.AppUtil inludes some methods to post keyboard/mouse event to OS.

AppUtil.typeKeys("AB<enter>");
//type shortcuts
AppUtil.typeKeys("<ctrl a><ctrl c><ctrl v>");
//Perform mouse click on screen
AppUtil.click(200, 200);

Add a Test Case

• QA/vclauto/A step by step example
  

Best practice

MUST READ THE SECTION BEFORE COMMITTING AUTOMATION CODE

Basic rules for JUnit 4

Rule. Recommend to follow Java code conventions
Rule. Don't miss assertions. One test method should include at least one assertion, otherwise the test will always pass.
Rule. Use assertions with an informative message.
Bad

assertEquals(expected , actual);
assertNull(actual);
assertNotNull(actual);
assertTrue(actual);

.

Good

assertEquals("actual should equals expected", expected , actual);
assertNull("actual should be null", actual);
assertNotNull("actual should not be null", actual);
assertTrue("actual should be true", actual);

Rule. Don't use assertTrue wrongly.
Bad

assertTrue("actual should be same with expected", expected == actual);
assertTrue("actual should equals expected", expected.equals(actual));
assertTrue("actual should be null", actual == null);
assertTrue("actual should not be null", actual != null);

Good

assertSame("actual should be same with expected", expected, actual);
assertEquals("actual should equals expected", expected, actual);
assertNull("actual should be null", actual);
assertNotNull("actual should not be null", actual);

Rule. Use assertArrayEquals instead of assertEquals for array data.
Bad

assertEquals("actual[0] should equals expected0", expected0, actual[0]);
assertEquals("actual[1] should equals expected1", expected1, actual[1]);
assertEquals("actual[2] should equals expected2", expected2, actual[2]);

Good

String[] expected = {"0", "1", "2"};
String[] actual = someMethod();
assertArrayEquals("actual should equals expected", expected, actual);

Rule. Avoid negation in an assertTrue or assertFalse test.
Bad

assertTrue("not empty", !r.isEmpty());

Good

assertFalse("not empty", r.isEmpty());

Rule. Don't catch unexpected exceptions.
Bad

public void testCalculation() {
    try {
        deepThought.calculate();
        assertEquals("Calculation wrong", 42, deepThought.getResult());
    }
    catch(CalculationException ex) {
        Log.error("Calculation caused exception", ex);
    }
}

Good

public void testCalculation() throw CalculationException {
    deepThought.calculate();
    assertEquals("Calculation wrong", 42, deepThought.getResult());
}

Rule. Avoid too complex test. One test should not contain too many asserts. Consider breaking the test scenario into multiple, shorter test scenarios.
Rule. Avoid external dependencies. Others can simply select one test and then run it without extra configurations. e.g. Data file should be placed in the svn with test code, so that newcomers don't need to manually prepare it.
Rule. Don't us random. That makes test uncertain, hard to debug and maintain. Instead of it, prepare enough special test data to cover boundary conditions.
Rule. Name tests properly. "testLoadFileFromServer" is better than "test".
Rule. Clean up in @After/@AfterClass method to avoid affecting other testcases.

Special ruls for GUI testing

1. Every test case should have verification point.
e.g. Test scenario: Inserting a table in text document.
After you inserting a table in the document, you have to verify whether the table is inserted successfully.
2. Make sure test codes are concise, readable and easy to maintain.
3. In VCLAuto, “sleep()” is usually not needed. Here is some special situation “sleep()” is needed.

• Open a file. If you want to do some operations based on a sample file or a new created file. “sleep()” is needed to wait for the file opened successfully.
  

4. Make sure test codes have no warnings.
5. When you add a new class, remember to add AOO license in front of the class.
6. Put same operations into “@Before” method to avoid codes redundant.
7. Use Ctrl+A, then Ctrl+Shift+F to format source code when you complete all the codes.
8. Test all the test codes on windows/mac/linux platforms before committing.