Wait Operations

When a user or a robot performs any simple action (such as pressing a button), they have to wait since it takes time for the application to execute a command and react to the action. The existing testing tools solve this problem in two different ways:

1. By waiting for a certain period of time. It’s the easiest and the most common method. All you have to do is to insert a wait/sleep operation in your code, for example:

for (SWTBotTreeItem item: items) {
	if (path[0].equals(item.getText())) {
		sleep(); // *** Wait for the Item to expand
		selectedItem = item;

From: Eclipse GUI Testing Is Viable With SWTBot

Obviously, it’s very unreliable. You can hardly plan the exact time for each operation to be executed, especially when it comes to long-lasting ones, such as source code compilation. If your waiting period is too short, your tests might fail simply due to the lack of time, for instance, when you run them on virtual or weaker machines and this would have nothing to do with your Application-Under-Test functionality.

On the other hand, if you put a longer waiting periods, it will affect your productivity. UI tests are time-sufficient by default; there are cases when a project with a large test base can be run for more than 24 hours. If you set your timeouts to 500 ms when it really takes 100 ms to execute an action, you can imagine that the whole project executes several times slower and it would conflict with principles
of Agile development.

2. By waiting for the operation to complete. It can be done by indirect means, such as using a message or a dialog in AUT user interface stating that the operation has finished. For instance, you can put in a command to wait for a label with the “Build Complete” message.

This approach is quite safe compared to setting a wait period. However, there are still two major limitations. Above all, it’s a time- and resource-consuming task to describe exact parameters of UI elements showing that the operation is complete. For example, the case of deferred tree expansion seems quite simple, however, in order to describe the criteria of the expanded tree, we need to know the total number of its children or a name of a certain
element. It becomes even more complicated when we deal with internationalization.

Another major problem is that sometimes there are no notifications in the AUT user interface whatsoever, especially on the early stages of development. It would also seem strange to label every internal operation graphically and announce its result to the outer world.

Alternatively, an experienced QA engineer, who is familiar with Eclipse Platform, APIs and Java can write a custom wait operation, such as

// ensure that all queued workspace operations and locks are released
ResourcesPlugin.getWorkspace().run(new IWorkspaceRunnable() {
	public void run(IProgressMonitor monitor) throws CoreException {
		// nothing to do!
}, new NullProgressMonitor());

From: Eclipse GUI Testing Is Viable With SWTBot

However, these tasks require highly skilled developers, which is too much of a valuable resource. The costs for most of the companies are too high and they are not ready to spare their human and financial reserve.

Q7 always knows when the operation is complete!

It may sound too good to be true, but QA engineers who work with Q7 do not have to put in a wait period. Or a wait operation itself. They don’t even have to know Eclipse APIs or how write a code. Because of Q7 Runtime Intelligence QA engineers don’t have to deal with waiting, Q7 does it automatically.