Blog

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

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...

Asserting context menus

During test case recording Q7 assertion mode allows to select a UI element in application under test and generate assertion lines in a script for selected properties. For instance, to check that “Save” button on Eclipse toolbar is disabled, we can switch to recording mode, select a button, check “enablement” property and click “Add”:

As a result, the following line will be appended to the script:

get-button "Save (M1+S)" | get-property enablement | equals false |
   verify-true

And in case this button is enabled during replay, test case will fail with a message: Assertion of enablement failed: expected:<false> but was:<true>

Yesterday one of our customers asked how to assert properties of context menus, as there’s a problem – once user switches to assertion mode, he cannot invoke context menu, as all user operations are blocked. And if context menu is open and then user goes to Control panel, context menu looses focus and closes. So, what can we do here to assert them?

Read more…