A good functional test can be represented like this:
Therefore, a test case takes an system under test in some well-defined state, performs some actions, which transfer a system into another state, and
then verifies that the final state is correct.
Thus, in a test case we need to specify the following:
Since the very beginning RCPTT had support for declarative description of an initial application state via contexts, and imperative
scripting language describing user actions, but there were no efficient way to verify a final state of an application - assertion
statements in scipt look very bulky and not very readable, they cannot be reused and it might take way too long to add assertions
for all aspects we want to check.
So we are filling this missing gap and introducing verifications - declarative reusable descriptions of various aspects
of an application state, and finally RCPTT test case description perfectly fits a picture from a beginning of this post:
During setup of inital state, it does not make sense to describe it completely - we need to describe and ensure only parts of a state which are
relevant to our actions. For instance, if we are testing About dialog, we do not care about projects in workspace or open views, and if we are
testing Package Explorer view, we don't care about Java compiler settings.
Same with a final state - it makes sense to check only those aspects of an application state, which supposed to be affected by performed
actions (or those aspects which should not be affected, but in theory might be affected because of bugs).
Though both contexts and verifications are about a state, there is a couple of important differences between them:
Currently released version contains four kinds of verifications: