Let us see, how various types of responses can be validated in vREST.
If your API returns the static response, then just set the Expected Body with the static response and Expected Status Code.
Let us suppose, your API returns the following static JSON response,
{ "vREST": [ "A simple and intuitive tool to quickly validate your REST APIs.", "Deliver zero defect web applications with very less effort in API testing.", "Works in hosted mode (http://vrest.io).", "No skilled resources required to validate your web application.", "Quickly generate documentation for your API specifications.", "De-couple your frontend implementation with backend implementation with easy to use Mock Server.", "Ease of maintenance over a span of releases." ] } |
For such scenarios, simply specify your static response body in Expected Body and set the Expected Status Code also as specified in the following image. Validator used for this scenario is "Default Validator".
Let us consider a scenario, where response contains random data (unpredictable data) or list of some unordered items. Only the schema/structure of the response is predictable. In such scenario, Default Schema Validator can be used.
e.g. let's suppose an API returns a list of random quotes. Since it returns a random list, so we cannot predict the outcome of this API. But what we know is the structure/schema of this response.
In the following response,
{ "quotes": [ { "quote": "Stay hungry, stay foolish.", "author": "Steve Jobs", "designation": "Co-founder, Chairman & CEO", "organization": "Apple Inc." }, { "quote": "If you're changing the world, you're working on important things. You're excited to get up in the morning.", "author": "Larry Page", "designation": "Co-founder & CEO", "organization": "Google" }, ... ] } |
For using Default Schema Validator, first we need to define the Expected Schema of the response as shown in the following image. We can use an external tool http://jsonschema.net to automatically generate the schema of our response.
Note:
Suppose, If your API which creates a resource on the server and returns some dynamic properties like _id, createdOn etc. And you want to ignore these dynamic properties during the response validation and also you want to check the email property with email regular expression. In such scenario, Default Validator can be used.
e.g. Let us suppose, the API returns the following response:
{ "_id": "536493015f56452a03000010", "createdOn": "2014-05-03T06:56:01.134Z", "name": "John Doe", "email": "john.doe@example.com", "designation": "Chief Technical Officer", "organization": "Example.com", "country": "India", "aboutMe": "My name can be used as a placeholder name and I don't have any identity.", "twitterId": "fake.john.doe", "facebookId": "fake.john.doe", "githubId": "fake.john.doe" } |
Now, the expected body should look like this:
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 "{{*}}": "{{*}}".
Let us suppose, the API returns the following response:
{ "key1": "value1", "key2": { "key2.1": "value2.1", "key2.2": "value2.2", "key2.3": "value2.3", "key2.4": "value2.4" }, "key3": "value3", "key4": "value4" } |
And in the above response, you only want to validate key1, key2.2 and key2.3 values.
For such scenarios, simply use the special variable "{{*}}": "{{*}}" (key-value pair) 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 key "key1" in your response, not the value of "key1", then you can mix this scenario with scenario 4 and write your expected body like this:
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 JSON response:
{ "id": "54a79b704cba8d5328d087f5", "resource_name": "testcase", "resource_url": "http://vrest.io/i/demo/m/RVD/create_resource", "resource_description": "This API creates a resource on the server", "meta": { "created_at": "2015-01-03T07:41:21.000Z" } } |
And let us suppose, the Update API returns the following response:
{ "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" } } |
Now, you can write our expected body like this:
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.
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.
For this scenario,
That's it. Now your test case will be validated with your custom validator when you execute it.
If you think, your scenario is not covered here then you can discuss your scenario with us by sending an email to "support@vrest.io". |
Note: