How to Verify Complex XML Structures: Part 2

The Library Grows…

Missed Part 1? Catch up here!

The library grows and now there are two shelves – science and literature with 3 books each:

Since I have only a few books in our library, I will run “get all books” query and get back the content of the library as an XML:

My task now is to check the author of Godel, Escher, Bach with Tosca.

Of course, as before, I can select the second book in the first shelf  and verify that the first property is the correct author by using the #<number> syntax:

In this case, the problems with this solution are quite obvious:

1. It is very hard to read
2. It will fail if the order of the data is not always the same – the librarian can put the books in a different order

So I need to create a more stable test case.

First of all I don’t have to know in which shelf the librarian has put the book. So I first have to find the correct shelf.

I can do that by selecting the shelf which contains a book with the Title Godel*. This is done by using the following Constraints.

Now I have selected the shelf with the book I am searching:

The XML representation of the shelf content looks like that:

Note: This even works if the librarian has put the book in the second shelf Literature. We are selecting the shelf by its content and not by its name.

Still I need to find the correct book in the shelf – so I have to repeat this step to find this book by using the constraints again:

This selects the correct book:

The book itself has a couple of properties –normally I find them on the cover of the book:

The XML representation of the book returns all registered properties of it as describedby nodes:

Now I am almost there – the final step is to select the right describedby property and verify the value:

If I want to check also when it was Published I just add:

This looks complicated however, and I want to hide this complexity from users by using reusable test step blocks.

The Power of Reusable Test Step Blocks

Let’s start by creating a test step library and drag & drop the XML test step into it, thus creating a reusable test step block (RTB).

Now, this would always search the same book so we want to have a more flexible way of adding parameters.

Right-click on the RTB (in our case it is called library) and select Create->Input Parameters.

You can now create parameters for your RTB:

I have created three parameters and grouped them by Search and Verify to make it easier to use them later:

The next step is to replace the actual values by the parameters. The syntax is: {PL[<parameter name>]}

Note: PL stands for Parameter Link.

You can also use drag & drop to set the parameters.

Now that I have prepared the test step block I can use it in my test case:

I already added a second step in which I search for Robinson Crusoe – I could also use TCD (test case design).

If you want to see the full content of the test step – press F11 or click on the small icon in the lower right corner.

I can now check the actual value:

Pressing F11 again will hide the details again.

As you can see we have now created a very flexible way handling XML data and I have even hidden the complexity from the user!

Stayed tuned for How to Verify Complex XML Structures: Part 3!

Part 1: The Library
Part 3: What About Xpath?

Want to know more? Watch our free webinar, “Web Service Test Automation 101” with Georg Thurner.

https://www.tricentis.com/resource-assets/web-services-test-automation-101-20141211/