As we continuing to use more complex web services we are navigating to www.xignite.com For using Xignite you have to be registered to their web site. after registering you can use a service free, for about 100 times. i think is enough to practice this topic. So i selected a service called XigniteMetals a service that provides Real-time Gold and Precious Metal Spot Prices. The Servicehas 15 operations, so i selected an operation that we can fully test GetHistoricalSpotPrice  the operation, returns a historical spot price for a metal.

Input Values

Output Values

Capturing the WSDL

Testing the Service

In the Summary Screen check the add XML checkpoint option. For each operation, the wizard generates default argument values with the proper value types. For each automatically created checkpoint (tests only), the wizard generates a generic XML structure as a place holder for the expected XML return values. Before you can run your test, you must replace the default values with the appropriate values for your test.

After creating a basic test, we want to make improvements. we want to tes more metals, different currencies and different dates. since the specific checkpoint tests past values i will rename it to MetalsPast

To modify the existing checkpoint select checkpoit properties we select the keyword checkpoint from the keyword view and pressing the Checkpoint button or alternatively, for the Expert view, by selecting the Checkpoint Properties context menu.

Object Repository - Before object repository state before renaming test object

Object Repository - After object repository state after renaming test object

Parameterizing the XML Checkpoint

We are only testing the values of the following fields. since we excluding the administration fields.

Click image to watch a XML parameterizing demonstration:

before last step, we need to parameterize the input values for the service.

Click image to watch a Web Service parameterize demonstration:

on the last step, we are about to add new valid information.

we are running the test in Update Mode, when test finished we are going to see the following results:

And why is exactly the test ended with status warning?
We can see the in the thirs iteration, the structure of the xml was changed...

a little more reserch will lead us to the checkpoint update on iteration 3. and we'll see that the structure was really changed. a new administartion field Message was added by the service, and we can't control it. Because of that, the checkpoint will fail, when testing data that uses other currency than USD or EUR. this is the big disadvantage of using xml checkpoints. lack of flexibility. to solve the problem we have to find a workaround or another solution. since another solution involve xml manipulation, which is not on this article scope, i will show you how to make an efficient woraround.

Workaround

Updating expected Results

Using Formulas in the Data Table

We have finished to design the test, you can run the test now. don't forget to select Run on all rows for the action call propertes.

Testing Dynamic Data is a different story, unless you can predict each value exactly. So, when testing dynamic we want to test the rersponse structure and pattern values ( e.g numeric, range of values etc. )

Terms like "negative test" and "positive test" are more of a concept than a strict activity. In both instances we are dealing with an input, an action, and an output. The action acts upon the input to derive a certain output. Both test cases can produce errors and, in fact, some say that the success of a test case is based upon the probability of it finding new errors in an application. positive testing is that testing which attempts to show that a given module of an application does what it is supposed to do.
Negative testing is that testing which attempts to show that the module does not do anything that it is not supposed to do.

in XigniteMetals web-service, we want to test that invalid information is handled correctly. for an instance, sending an invalid date, should fail the service and notify the service consumer, by not doing so, we have a problem. The first thing that comes up in our mind is senf invalid currency type and/or invalid metal symbol. as soon as you call the service using an invalid metal symbol or/andnot supported ciurrency you'll get the following exception.

The toolkit WSE 3.0 raise the exception because the first two parameters are strictly defined by the service, and not handeled by the service provider. the only value we can "play" with is the AsOfDate field. we are going to use a single checkpoint as the following :

The expected messages ( results ) must not be tested accurately, but approximately enough, using a regular expression.