Lets look at how the Assertion functionality of the Sampler TestSteps are used to validate the incoming response or request received by the TestStep. Before we dive into the available assertions, lets do a quick overview;

Assertions are used to validate the message received by a TestStep during execution, usually by comparing parts of the message (or the entire message) to some expected value. Any number of assertions can be added to a sampler TestStep, each validating some different aspect or content of the response. After a sampler TestStep executes, all its assertions are applied to the received response and if any of them fail the TestStep is marked as failed in the TestCase view and a corresponding FAILED entry is shown in the Test Execution Log;

Here we can see that the "Test Request: login" TestStep has failed, which in the TestCase Run Log at the bottom also displays details on the actual assertion failure; "[Not SOAP Fault] Response is a SOAP Fault" means that the "Not SOAP Fault" assertion failed, ie the response was a SOAP Fault message.

Managing Assertions

Assertions are always displayed in a tab at the bottom of the containing TestSteps' editor window;

In the screenshot above you see the 3 assertions added to a SOAP Request TestStep, the first two passed ok for the last response but the last one failed (as we also saw on the previous screenshot).

The toolbar on top of the assertions allows you to add, configure, delete, move and clone assertions as required and the right-click popup menu for an assertion contains similar actions  (as can be seen in the screenshot). Double-clicking an assertion brings up its configuration dialog if available.

Adding an assertion is straight forward; press the right-most button in the toolbar, which opens a dialog which prompts you to choose which assertion to add;

The list will contain those assertions available for the current type of sampler (see below), pressing OK will add the assertion and open its configuration dialog.

Common Assertions

A large number of assertions are available for validating received messages, some being specific for a certain type of TestStep and some being common for all TestSteps. The assertions available for all TestSteps are:

• Contains - checks for the existence of a specified string (see below)
• Not Contains - checks for the non-existence of a specified string (see below)
• Reponse SLA - check the response time against a specified value (see below)
• XPath Match - compares the result of an XPath expression to an expected value (read more)
• XQuery match - compares the result on an XQuery expression to an expected value (read more)
• Script - runs an arbitrary script that can be used to validate the received message as desired (read more)

The first three of these are covered in more detail below.

TestStep specific Assertions

A number of assertions are available that are specific to one or several types of TestSteps. These are covered in more detail together with the corresponding TestStep but also listed below to give you an overview:

For SOAP Request TestSteps the following assertions are available (see Validating SOAP Messages for more details)

• Schema Compliance - validates the response message against the definition in the WSDL and contained XML Schema
• SOAP Response - checks that the response is a valid SOAP Response
• SOAP Fault - checks that the response is a SOAP Fault
• Not SOAP Fault - checks that the response is not a SOAP Fault
• WS-Security Status - validates the WS-Security headers and tokens in the response
• WS-Addressing Response - validates the WS-Addressing Headers in the response
• JMS Timeout - when using a JMS endpoint that specifies a response channel this assertion validates that the response is received within the specified time
• JMS Status - when using a JMS endpoint, this assertion validates that no JMS-related errors occured

For REST Request TestSteps the following assertions are also available

• Schema Compliance - validates the response message against the schema that has either been specified in an underlying WADL file or that has been inferred from the response.

For JDBC Request TestSteps the following assertions are also available

• JDBC Timeout - validates that the result is received from the target database within the specified time
• JDBC Status - validates that no JDBC-related errors occured

For MockResponse TestSteps the following assertions are available

• Schema Compliance - validates the request message against the definition in the WSDL and contained XML Schema
• SOAP Request - checks that the request is a valid SOAP Request
• WS-Security Status - validates the WS-Security headers and tokens in the request
• WS-Addressing Request - validates the WS-Addressing Headers in the request