The latest version of soapUI, soapUI 4.5, brings us a new approach to validation. The key improvements are:
A new dialog for adding assertions
The Message Content Assertion
Improved Assertion Adding
A new dialog for adding an assertion now presents them in categories and adds small and clear explanations to each assertion. This way you can easily explore all assertions and find one that you are looking for or choose a different one.
This dialog has two versions; one when you are adding an assertion to a request test step and for Assertion Test Step. The version for Assertion Test Step allows users to assert properties in addition to request a response (which is the case for request test steps). Also, it will clearly mark what assertion you can use, enabling and disabling assertions that are not appropriate for the selected source and property.
Message Content Assertion
The Message Content Assertion allows you to take a snapshot of an API response and lets you use that as the baseline for comparing all data nodes in future responses. In a way you can see this as and aggregation of the existing soapUI XPath Assertion.
It shows the response XML that you have at the moment of configuration, and that XML is used as a snapshot for configuration. On each line that has some value, you can apply a comparison rule.You can see this as XPath Assertions and validating node values attributes.Using checkboxes you can enable or disable rules. The other columns should be self-explanatory.
The thing to notice here is that configuration XML could be different, and usually is, from the actual XML which is asserted. Confused?
Imagine that you send a request and then you get a response. Let’s call this response ResponseOne. Now you create Message Content Assertion and configure it. When you send the next request you get a different response, let’s call it ResponseTwo. ResponseOne and ResponseTwo are different but XPath expressions created using ResponseOne will be executed against ResponseTwo, and if they can find nodes values and attributes, they will be compared to the expected values. To use other XML for baseline you need to reconfigure this assertion.
This may look confusing but actually this is what a tester is doing when adding XPath or XQuery assertions one by one. This time they are put in one box for easy access.
Previously you have only been able to set assertions on specific requests and responses. If you needed to assert some property you had to use Groovy, which can be problematic for some testers. The Assertion TestStep is a new TestStep that allows you to assert several items at the same time. For you that means you can assert a response from a previously executed request TestStep and a value of a custom property on the TestSuite level. This is possible with the other version of a dialog for adding an assertion I mentioned above.
Here you can add an assertion as you do on request TestStep and on property values. What is particularly nice about the Assertion TestStep is that you can group them in logical AND or OR groups and that you even are able to group groups. This way you can create a sophisticated validation scenario. Notice that you cannot assert a TestStep that comes after Assertion TestStep and a property that are asserted at the moment when Assertion TestStep is executed. That means if you are asserting a response, the Assertion Test Step will take the response value at the moment when it is executed (Assertion TestStep) not when the response is received like it is when you add assertion on the Request TestStep.