Question about match more than one row from DB2 table with Rest webservice response
Is there any option in SOAtest to match more than one row from DB2 table with webservice response ( I have put multiple assertions to achieve this , but the problem I would see is if DB2 returned rows increased in future)
i was able to match one row from DB2 table with rest service response -
Current scenario –
Number of DB2 rows count - 3 rows and 2 columns = 6 values
Service response count - 3 * 2 = 6 values
Total assertions – 6 assertions to match values
Future possible scenario – let say we have inserted more rows and DB2 table count become 10 rows
Number of DB2 rows count - 10 rows and 2 columns = 20 values
Service response count - 10 * 2 = 20 values
Total assertions – 6 assertions ( since we have automated above test case with 6 assertions only)
Problem – only first 3 rows compared and reaming 7 rows skipped – I want compare all 20 values without adding insertions.
We can automate this by writing custom script or cucumber , but– is there any option to automate this kind of scenario in soatest ?
Spent considerable amount of time to find out option in SOAtest – nothing worked out
Answers
-
The easiest way to do this is to probably to script it. There is no builtin assertion that will handle tabular data.
0 -
I've seen at least a few different approaches to accomplish this type of validation.
One approach is to use the XSLT Tool to translate the DB Tool's SQL result set XML to the same format as the response message, store the result to a data bank column, then use a Diff tool (for example) to compare the response message against the data bank column. In the case of JSON responses, you would use the XML Converter tool to first convert the JSON response to XML. Alternatively, you could also do the opposite, where you use the XSLT Tool to convert the response message into the same format as the DB Tool's SQL result set XML. XSLT is a very powerful way to transform XML in one format to another. The downside being that you need to be able to write the XSL document specific to the data you are working with.
Another approach would be to literally script the entire validation. You could store the DB Tool's SQL result set XML into one data bank, store the JSON response into another databank, then use the Extension Tool to run a script that would parse both documents and compare them in some way. The downside is that this requires scripting and is questionably less elegant than using XSL to covert one or both documents into a common format for direct comparison.
A third approach is to store the values from each row in the DB Tool's SQL result set XML to a Writable Data Source. This involves chaining an XML Data Bank to the DB Tool's SQL result set output, creating an extraction for each column in the result set. In this way, the values from reach row in the SQL result can be written to each row in the writable data source. Similarly, do the same thing for the response message, using a Data Bank to write the value from each repeating item in the response message to another writable data source. The outcome will be two writable data sources, each with the column and row data that needs to be compared, one from the result set and one from the response message. To compare both writable data sources you would have a second scenario that would iterate over both writable data sources, comparing the values from each column with each other. The test steps that are writing to the writable data source would need to be in one scenario and the test that needs to iterate over them to compare the values would be in a different scenario. The writable data sources need to be in the parent suite of both scenarios for this to work. The test setup for this one is a little complicated but eliminates complex scripting or having to write an XSL.
1 -
Hello learnsoatest,
I wrote an article showing one way to compare Database values with those from a webservice response. This may help you achieve your use-case.
0
