Archive «Q7»

Supercontexts

Introduction

A test case in Q7 consists of two parts:

• list of contexts, defining an application state
• ECL script describing UI actions and validating that application behavior in given state is correct.

In some cases it might be required to execute same actions with just a few variances in initial state or arguments of script commands. Common examples are:

• Test case verifies that a project can be built. An executed action is just a verification that Problems view is empty, but this should be done for several different projects. We can say that we have the same behavior for different states of workspace.
• Test case verifies some form (like a validation of new Java Class dialog). We execute basically the same actions (type values in fields and check error message), but with different command arguments.

Read more…

Default Contexts

It’s good practice to make test case to be focused on testing functionality itself and all operations for preparing application  should be moved out from test case to some place. In case of Q7 the contexts is the right place for these purposes. Q7 contexts are applied to application before test case execution. In eclipse there are several groups of standard mutable configurations/states: preferences, workspace, workbench.

In the process of using Q7 to create test projects, we came to the conclusion that some contexts should be executed before each test cases. For example, when testing JDT before each test should be cleared Workspace and Working Set, and terminated all active launches. Initially for these purpose Group Context is used, this context should be added to each test case in Q7 project. But this practice was uncomfortable, because at the addition of a new test case, it was necessary not to forget to add the Default Group Context. Since version 1.3 of Q7 introduced the concept of the Default Contexts list.

At the creation new Q7 Project the “Project Settings” file is created automatically:

Description of project can be given in “Description” section of the “Project Settings”. Default Contexts can be set in “Default Contexts” section. Contexts to default contexts list can be added from this Q7 project and also from related Q7 projects.

These default contexts are displayed in test cases. Sequence contexts defined in the Default Contexts  list can not be changed in the test case and custom contexts can be added to test case only after default contexts. “Project Settings” can be opened from test case by clicking on “Configure Project Default Contexts” link.

At the replaying test case the default contexts are displayed in “Execution View”. Custom contexts are executed after default contexts execution.

More information about the creation and application of Q7 contexts you can get from the Q7 demos - http://q7.xored.com/demos.

UI Testing of rulers in source code editors

Rulers are important part of modern IDEs, which can display a lot of information, like here:

In this post I am going to illustrate Q7′s built-in support for rulers and describe how to create a couple test cases for various rulers. As an example we are going to use Java editor and a simple “Hello, world!” Java class, like on a screenshot above. A sample Q7 Project with tests is available at Github – https://github.com/xored/q7.examples.rulers

Read more…

Test your plugins on multiple versions of Eclipse

Typically UI testing tools work with applications. But what if a final product is an update site? While it might be acceptable to install features under development into some version of Eclipse during test creation, when it comes to continuous integration things get more complicated. Creating some RCP application which includes required features requires extra effort and may significantly slow down the build.

Read more…

Script parameterization

Note: this post is outdated and the same functionality can be achieved in more efficient way by using supercontexts.

One of the most asked features for Q7 is to execute a same test with different parameters. I’m going to demonstrate how it is possible to achieve the same effect using ECL. As an example, let’s test error messages in JDT New Class Wizard. We start with a Java project with a single class:

At first, let’s record an initial script which launches new class wizard, sets package and class name and asserts an error message:

get-view "Package Explorer" | get-tree | select example | get-menu "New/Class" | click
with [get-window "New Java Class"] {
    get-editbox -after [get-label "Package:"] | set-text "org.example"
    get-editbox -after [get-label "Name:"] | set-text Class1
    get-editbox -after [get-label "Java Class"] | get-property text |
       equals "Type already exists." | verify-true
}
 Read more...