Previous Topic: Drag and Drop a FilterNext Topic: Add an Assertion


Assertions

An assertion is a DevTest code element that runs after a step and all its filters have run. An assertion verifies that the results from the step match expectations.

The result of an assertion is a Boolean value (true or false).

The outcome can determine whether the test step passes or fails, and also determines the next step to run in the test case. An assertion is used to change the test case workflow dynamically by introducing conditional logic (branching) into the workflow. An assertion operates very much like an "if" conditional block in programming.

For example, you can create an assertion for a JDBC step that ensures that only one row in the result set contains a specific name. If the results of the JDBC step contain multiple rows, the assertion changes the next step to execute. In this way, an assertion provides conditional functionality.

The test case flow is often modeled with one of the following two possibilities:

The choice depends, usually, on the actual logic being employed.

Note: If an assertion references an unresolved property, a model definition error is raised. The model definition error does not cause the test to terminate, but it cautions the test author that an unresolved property was encountered. The problem that an unresolved property creates is that an assertion cannot give the proper verdict because the assertion does not have enough information. Not having enough information results in false positives or false negatives. (Most of the assertions return "false" if an unresolved property is encountered, but that is not an enforced rule.) By running a test in the ITR and inspecting the test events panel for model definition errors, you can determine if any unresolved properties exist.

You can add as many assertions as are necessary, which gives you the capability to build a workflow of any complexity. Assertions are the only objects that can change the DevTest workflow.

Note: Assertions are executed in the order that they appear, and the workflow logic usually depends on the order that the assertions are applied.

After an assertion fires, the next step can be configured as the assertion determines, and the remaining assertions are ignored. Each time an assertion is evaluated and fired, an event is generated.

Global and Step Assertions

As with filters, you can apply assertions as global. That is, assertions can apply either to the entire test case cycle or as a step assertion, where they apply only to a specific step.

This section contains the following topics:

Add an Assertion

Assertions Toolbar

Reorder an Assertion

Rename an Assertion

Drag and Drop an Assertion

Configure the Next Step of an Assertion