Q7, 15.08.2013 by Ulyana Skorokhodova
Test Suite is mostly for Runner support.
Typical scenario with Q7 is to run all tests from project(s) either from IDE or Runner, but some people would like to execute predefined number of test cases, like “sanity check suite”.
So you can create suite,
drop tests there
and use suite from Runner.
In Test Suite tests are sorted alphabetically but is doesn’t mean that they will be executed in such way.
Test execution order.
Q7 tests do not depend each other. All the setup for your AUT shall be handled by Contexts
It is not really random, there are some heuristics to speed up test base execution like clustering test cases, which are requires similar set of files, perspectives, views, etc, but now it is enforced only at server execution.
So please consider test execution order as “random” in terms there is no predefined order during test cases execution.
Q7, 11.07.2013 by Ulyana Skorokhodova
Sometimes for our testing we need to specificly configure AUT launches. Launch Context
Launch Context serves the following porposes:
- Add Launch Configurations and/or run the required ones
- Add breakpoints and pause a required launch at a breakpoint
- Terminate existing launches (optional)
- Clear launch configurations (optional)
- Clear breakpoints (optional)
Thus you may flexibly adjust your AUT Launch Configuration state to make everything ready
for test creation.
Q7, 9.07.2013 by Ulyana Skorokhodova
If you need to prepare your AUT workspace you use a Workspace Context
which places files on a workspace before a test execution. But sometimes you may need to put data somewhere outside your AUT workspace – anywhere on your disc space. Folder Context
was coined for this purpose. When it is applied it puts files into a selected root folder.
Above is a Folder Context which puts img1.jpg
files in a TestData folder
on a C disc
. You can also add a folder with files:
Q7, 11.06.2013 by Ivan Inozemtsev
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.
Q7, 16.05.2013 by
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.