API was always a topic that I waned to explore more, I decided to start writing this blog in phases while learning more about it instead of taking some notes elsewhere separately.
- By the same occasion, I find out that Dave Westerveld published a book, so it’s such an exciting start with more supporting resources from the testing communities around me.
Those are the reasons that motivated me to go further and tell you about API Testing from scratch.
PART1: Discovering API
What is API and API Testing ?
- Starting with API: Application Programming interface, it’s like 2 pieces of code talking together.
The below picture is a great presentation from Dave book that explains the responsability of API Layer to fetch data from the backend to display into the frontend and and viceversa. So it’s like a way to communicate between 2 layers.
Eg. Website talking to database backend, mobile app talking to an authentication form …
If API layer has been tested correctly it will show the correct data onDave
the frontend and ensures that the data insertion will also work fine.
- API Testing: In the presence of front and backend there is necessary an API sitting between, we need to test those APIs and their integration.
How it works?
A client application sends a request to an API, which interacts with a backend system or server.
Example, you went to a restaurant (client application) where you wanted to eat ….., so you make an order (the request) to the waiter (who is the API) that goes to the chef, he take the order and brings the food from the kitchen and then deliver it to the client (the response)
Why the need of the waiter ?
You may ask why I don’t ask directly the chef? well simple, imagine you are a tourist somewhere and you wanted to eat chienese noodles but the chef don’t speak english. So the waiter will be your interface and helps you interact independently from the language of your chef (independent from the backend). Same API can be used for WEB, mobile, iOS, android. …
Types of API
There are 2 types of API Automation SOAP and REST Assured both are the web services.
- SOAP: Simple Object Access Protocol
- REST Assured: Representational State Transfer
API Vs. Webservices
Web services are services used by applications communicating over the same network (usually internet), but API does not require internet connection in general. API is a communication layer between application which probably don’t use internet.
- A Web service facilitates interaction between two machines over a network
- An API acts as an interface between two different applications
PART2: API Testing Strategy
We want our API to
- Be Correct
- Provide value
- Intuitive to use
There is an Heuristic for that called POISED [Parameters, Output, Interop, Security, Errors, Data]
- Parameters: Play with parameters and try to use empty entries / random entries and see what’s happen: Find out how it reacts in different conditions
- Output: try to delete a number for example and see the output what’s actually happen ? change the output to xml for example and check the output, try to change the date format and see the output, you can find just an error code status like 500 internal server error instead of showing a clear message what happens exactly so there’s a lot of ideas that you can communicate to developers
- Interop: an api is about communication, check if other services can get the information they need. you can think about changing the date format from yyyy/mm/dd to dd/mm/yyyy and see if they managed the difference. understand business need,what app developers looking for. if you have good interoperability it makes it easier
- Security: secuity at ui level is good but not enough, your api can be reached from somewhere else, think about updating the user or change the token and see if you still having data
- Errors: what if we send incorrect credential, is the status change? change value to null and checkout tif the communication is well done ? or it’s just written ‘bad request’ checkout invalid date format ?
- Data: make sure you are collecting the right data you want to have
ask the API if I have 10000 what can happen ? think about scalability
collection runner is a good way to make a collection of different data and run them at the same time.
Plus that POISED heurstics, there is a section called ‘Tests’ where you can find ready code snippets that allow you to check basic functionalitities
Data Driven tests: Get the data using the collection runner and run your tests (checkout the below picture)
Tips how to catch bugs via API Testing ?
Kristof_vk did an excellent racket API Testing – How I hunt for bugs ? with amazing tips how he can find bugs while exploring an API, his racket is a good example if you want to learn outstanding scenarios about funny bugs he found.
PART3: Mocking in APIs
Mock is a method/object that simulates the behavior of a real method/object in controlled ways
mocking is creating a virtual service that works like a real service. it’s like pretending and imitating a real – it contains definitions for operations that clients call, receives requests, and returns simulated responses.
Refering to Beth Marshal course, there are 3 main ways mocks can be created in postman
- Mock server based on specification file when you have the right documentation to handle the API
- Mock server from scratch by adding request and tell what response to return
- Add a mock server to an existing postman collection
PART4: Newman for CI/CD
In order to install newman, you need to have node already installed in your machine then run
- npm install -g newman
- nodejs plugin is required in jenkins (to be installed)
Useful Resources about API
It’s important to know first about different HTTP status codes they are like short notes from a server that get tacked onto a web page. as we saw in the above example the food is not present directly in front of the client but brought to him by the chef from the kitchen depending on his customized request. At that moment it’s like there are messages letting you know how things went when it received the request related to your order.
The below drawing introduces several server HTTP Status Codes including informational, success, error codes or redirections, that code can tell you what’s happening on the server behind the scenes!