A test case in RCPTT consists of two parts:
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:
So we have added supercontexts which can be used to cover both of scenarios above. A supercontext is a list of contexts
of the same type, which can be refered in test cases just as usual contexts, but during an execution, a test case will
be executed several times with each of these contexts. In this blog post we are going to describe how to create test cases
for two examples mentioned above.
We are going to create a test case which verifies that Problems view contains no errors for the following states of a workspace:
We start with a creation of a usual test case which verifies that Problems view contains no errors.
Next, we create three more workspace contexts:
Then we create a new workspace supercontext (by selecting New -> Super Context) in a context menu in Test Explorer and add all
our four workspace contexts into it:
Now we can get back to originally created test case and replace Emtpy Workspace context with Workspaces supercontext.
If we execute this test case, an Execution view shows it has been executed four times, each time with different workspace context:
For the next test case we are going to reuse Java Perspective workbench context and HelloWorld Java Project workspace context.
We record a filling values in New Java project and validating an error message:
Now we need to parameterize it - at first we create Parameters context "Valid Input" with parameters we are going to change:
At second we replace string values in script with $paramName and adding parameters context to a test case:
And the rest is straightforward - create parameters context for each set of input values, put them into parameters supercontext and put this supercontext into testcase.
Once test case is executed, we can see that all inputs were iterated:
If a test case refers to more that one supercontext, then all possible combinations of tuples from these supercontexts
will be used. For instance, for our example above if we would like to check that all these Java projects can be built both
with Java 1.6 and Java 1.5 compiler settings, we could create Preferences supercontext with two contexts 1.6 and 1.5, add
it to a test case, so that it will be executed 8 times and Execution view would show a list like this:
In case we need to iterate over context pairs without this 'cartesian product'
(like, workspace context and parameters context specific for this workspace), this can be done by
creating a single group supercontext, referencing to several group contexts. For instance, if we create a test case
which validates a build error count, then we can have a structure like this:
Supercontexts are powerful but might be hard for inexperienced users. In case when there are only a few variances of a test case which are
unlikely to be changed, it might be much more easier and faster to create few separate test cases instead of dealing with parameterization.