Call Darth VADER to help you test the APIs
Everyone has heard of Darth Vader from Star Wars, but remembering him when testing an API may be new to you. The use of VADER Heuristics will help you to focus on testing APIs. It will remind you of some of the key points that need to be tested.
But do you know what a Heuristic is?
Gabriel Santos wrote a whole post about it and he defined it as:
Heuristics are processes that occur naturally in the human mind. They help to solve problems and make decisions in conditions of uncertainty, replacing the complex way of doing something with a simpler one and still bringing satisfactory results.
In this article, Amos Tversky and Daniel Kahneman, psychology scholars, define heuristics as:
“Principles that reduce the complex tasks of assessing probabilities and predicting values for simpler judgment operations.”
That is, it is a way to invent a shortcut so that you can remember important information. We go through this phase of Heuristics a lot when we are studying for the entrance exam and the teachers create this to facilitate their studies.
THE VADER
This is a heuristic already known in the world of API testing. It was created by Stuart Ashman. My intention today is to dissect it, to bring you what each letter from Vader means and how to use this heuristic to boost your test results.
We start with the V for Verbs
Verbs in an API are none other than Request types. First of all, it is important to know where each one should be used and why it is used within your Business Rule.
POST — Usually used to add or create new records.
PUT — Commonly used to edit previously created records. A key point here is that the PUT must and can be sent multiple times, and with the same data, and the state of the server will not be changed regardless of the number of requests made. Unlike POST, a new record is added to each new request.
DELETE — This is simple. It will exclude, but know your reality. Is your Business Rule defined to exclude the record? Or just to tag it as “inactive”?
GET — The GET is the SEARCH. We can search all records or search for a specific one by sending a parameter, be it an ID, name or any other, and it also depends on knowing and understanding the characteristics of your product.
Yes, these verbs are just the most used and there are a few others within the API tests and we must make sure that all requests are working as expected.
To test these verbs is to execute the requests, send POST, PUT, GET and DELETE. Execute all the verbs and pay attention to what the expected behavior is of each one.
Authorization
It is at this moment that we must pay attention to variations in authentication and authorization. Authentication is your ID, who you are. Authorization is what you are allowed to do.
Some scenarios that we can exercise are: Login successfully, recover the Token and use that Token to access authorized resources. Attempt to access resources that the Token is not authorized for. Use an invalid Token, and a Token from another user.
Here are some examples:
Login successfully, status code 200 OK and returns the token that will be used in other requests.
Trying to change a user’s password, but I passed the token of a 3rd user. API returned 401 Unauthorized, as I cannot change another user’s password.
Another example is the verb GET trying to search for profile information without passing the Token. The API answered correctly again, informing me that I am not authorized to make this request.
D of Data
Here the focus should be on the data for each requisition, using variations that make sure that they are obeying the business rule:
· Type: if the data is a string, it is returned as a string, integer, boolean …
· Format: can be an array or a simple field.
· Data size: maximum, minimum quantities for each field.
· List pagination.
Here we can check for an error in the data returned by the request. We passed the value “false” to the active attribute, but the API returned the same attribute with the value “true”.
The list returned in the GET request has the attribute “qty” with a value equal to 29, in the request parameter the quantity of 10 must be returned per page. The page counter “pagCount” has a value of 2, so 9 items will not be displayed on the screen, as they were not included in the pagination.
E of Errors
We can validate the errors, the error codes, check if the errors are being handled, or if some combination of data is returning an internal server error (error 500).
Having a 500 error in the application is not good practice, as it represents a failure in the logic implemented for a business rule. Now is the time to investigate the error and talk to the developer to fix it.
The “user” field, which must be of a single value, was sent with an existing value in the database. The API is returning a 400 error (Bad Request) and describes the problem found in the request in what is returned. Ok, the API did not allow a breach of the Business Rule, but a person already registered should return a 422, as it is related to the business rule and not to the contract which is the 400. Another good time to talk to your developer and deal with this exception .
For some reason it was not possible to perform the PUT request on the route, but the error is not handled, so the user or the tester cannot know the reason for a failed request.
R of Responsiveness
Responsiveness concerns the reaction of the API, how the response behaves. Is the response speed as expected? Is it stable?
Be aware that the responsiveness of the API is quite different compared to what we tested in web applications, where the layout of the application with different screen sizes and resolutions would be analyzed.
When a request fails, is the time to return the error as expected?
Are time-outs happening? In what situations? Sporadic or constant?
Is the API responding satisfactorily to a high number of simultaneous requests?
Heuristics are mental shortcuts that can help us to cover some very important scenarios. In the example of VADER we managed to go through several key points of a basic API.
So, did you like it? Can you apply it on a daily basis?
References:
As always the three names API references for me, Júlio de Lima, Antonio Montanha
Vinicius Pessoni — Canal Pessonizado
Gabriel Santos — And your post about Heurísticas
And Stuart Ashman Post
