Page Comparison

Scenario 3: My API returns a very large response and I am interested in validating only a small part of my API response.

If you want to validate only a small part of your API response and want to ignore rest of the properties then you can use special variable as xml tag <__STAR_VAR__/>.

Let us suppose, the API returns the following response:

<?xml version="1.0" encoding="UTF-8"?>
<contact _id="536493015f56452a03000010">
   <aboutMe>My name can be used as a placeholder name and I don't have any identity.</aboutMe>
   <country>India</country>
   <createdOn>2014-05-03T06:56:01.134Z</createdOn>
   <designation>Chief Technical Officer</designation>
   <email>john.doe@example.com</email>
   <facebookId>fake.john.doe</facebookId>
   <githubId>fake.john.doe</githubId>
   <name>John Doe</name>
   <organization>Example.com</organization>
   <twitterId>fake.john.doe</twitterId>
</contact>

And in the above response, you only want to validate name and email values.

For such scenarios, simply use the special variable in xml tag <__STAR_VAR__/>  to ignore rest of the keys and values. Now, the expected body should look like this:

Further, let us suppose, you want to validate only the existence of data in country tag in your response, not the value of country tag, then you can mix this scenario with scenario 2 and write your expected body like this:

Scenario 4: My API returns some response in which some part of the response can be obtained from the responses of previous test cases.

Let us take an example in which one test case creates a resource on server and second test case updates that newly created resource.

• Suppose you have an API which creates resource on server and returns the following XML response:
  
  

  Code Block
  theme Confluence language js title Status Code: 200 linenumbers true
  <?xml version="1.0" encoding="UTF-8"?> <contact _id="536493015f56452a03000010"> <aboutMe>My name can be used as a placeholder name and I don't have any identity.</aboutMe> <country>India</country> <createdOn>2014-05-03T06:56:01.134Z</createdOn> <designation>Chief Technical Officer</designation> <email>john.doe@example.com</email> <facebookId>fake.john.doe</facebookId> <githubId>fake.john.doe</githubId> <name>John Doe</name> <organization>Example.com</organization> <twitterId>fake.john.doe</twitterId> </contact>

• Now, you can save the _id of newly created resource into variable say "resourceId". You can extract the variable in the following way:
  Image Removed
  Image Added
  
   Few points regarding writing Path in the above table:
  • Each individual property value can be extracted via JSON XML Path (XPath) expression e.g. `id` or `meta.created_id``_id` 
  • For more information, read JSON XML Path syntax
• Now you can use these extracted variables in subsequent requests. Note that once a variable is defined, it can be used in all subsequent requests within that test run only. If you want to override this variable, simply re-define the variable in any request.
  
  Now, suppose you have an API which updates this newly created resource and it needs the ID of the resource to update. You can use the {{resourceId}} variable (extracted in previous step) in the URL as shown in the following figure:
  Image Removed
  Image Added

• And let us suppose, the Update API returns the following response:

  Code Block
  theme Confluence language js
  { "id": "54a79b704cba8d5328d087f5", "resource_name": "[Modified]testcase", "resource_url": "http://vrest.io/i/demo/m/RVD/create_resource", "resource_description": "[Modified]This API creates a resource on the server", "meta": { "created_at": "2015-01-03T07:41:21.000Z", "updated_at": "2015-01-03T07:51:01.000Z" } }<?xml version="1.0" encoding="UTF-8"?> <contact _id="536493015f56452a03000010"> <name>John Doe Modified</name> <aboutMe>My name can be used as a placeholder name and I don't have any identity.</aboutMe> <country>India</country> <createdOn>2014-05-03T06:56:01.134Z</createdOn> <designation>Chief Technical Officer</designation> <email>john.doe@example.com</email> <facebookId>fake.john.doe</facebookId> <githubId>fake.john.doe</githubId> <organization>Example.com</organization> <twitterId>fake.john.doe</twitterId> </contact>

  
  Now, you can write our expected body like this:
  Image Removed
  Image Added
  
  Note: In the above test case, fields "_id" and "created_at" will be replaced from the values extracted from previous test case, and updated_at value will be replaced from the value received the actual body, before response validation. So, we can use Default Validator in such scenarios.

Scenario 6: My API returns dynamic response and none of the above fit to my needs.

In vREST, most of the responses can be validated with the help of built-in response validators "Default Validator" and "Default Schema Validator". But if that doesn't fit your needs, then you can define your own custom validator in vREST or you can even mix and match validators and assertions.

• Custom Validator is basically a Javascript function and vREST invokes this function, if you associate your custom defined validator with the test case. 
• vREST provides expected response and actual response to this function.
• Now, its your job to validate expected response with actual response. 
• If you return true then vREST will mark the test case as passed and otherwise failed.

For this scenario,

Image Removed

Image Removed

• .