APIs from Automation testing perspective
Guess who am I
Not White… Nor Black ,,,
Not “un-readable” Code… Nor BDD Test case,,,
I connect the two sides of a software,,,
AND,,,
I respond back whenever someone HIT me…
APIs testing act as an early alert stage for e2e phase. It can be a good addition for your test suite against any software.
In Most of my projects that i toke my testing share from, i was by somehow concerned about APIs more than the frontend as i can discover and report issues earlier and then re-test it before invlolving or even starting with the frontend efforts. I can technically separate and handle backend developers than frontend ones.
So, as a result, and after implementing the frontend work, I will be mostly focusing on design QA and UI issues.
Now,,, Lets focus on story Title…
I will start with what you need to know and understand before you start:
Hitting some “poor” endpoint and dumping a huge JSON (and not formatted properly) in-front of a developer
First things first
Understand what’s the API all about; how it works, and how can you get and feel the benefits of API testing to avoid conflicts between teams. It’s worthy to mention that issues reporting during API testing phase can reduce the frontend team efforts significantly.
Deep learning and digging more in APIs depth is a challenging learning curve and requires some time, however, I am trying to focus on how can you automate those endpoints to make your life easier as a QA Engineer.
Introduce yourself to
API Types
I used this link as a reference for you to list down the main differences as well as some dis/advantages for both SOAP && REST
SOAP is definitely the heavyweight choice for Web service access. It provides the following advantages when compared to REST:
- Language, platform, and transport independent (REST requires use of HTTP)
- Works well in distributed enterprise environments (REST assumes direct point-to-point communication)
- Standardized
- Provides significant pre-build extensibility in the form of the WS* standards
- Built-in error handling
- Automation when used with certain language products
REST is easier to use for the most part and is more flexible. It has the following advantages when compared to SOAP:
- No expensive tools require to interact with the Web service
- Smaller learning curve
- Efficient (SOAP uses XML for all messages, REST can use smaller message formats)
- Fast (no extensive processing required)
- Closer to other Web technologies in design philosophy
Another important topic to cover
Understand Standard HTTP methods and when to use, besides, status code and when to expect this code or that one.(supposedly you are familiar with HTTP)
Main HTTP methods that you will interact with while API testing:
- GET : Can be used for data requesting from a specified resource.
- POST : Can be used to send data to a server to create/update a resource.
- PUT: Can be used to send data to a server to create/update a resource. (diff can be spotted in references)
- HEAD: Almost identical to GET, but without the response body.
- DELETE: The DELETE method deletes the specified resource.
- OPTIONS: The OPTIONS method describes the communication options for the target resource.
AND,,,
HTTP status code:
- 100s => Informational response
An informational response indicates that the request was received and understood
- 200s => Success
This class of status codes indicates the action requested by the client was received, understood and accepted.
- 300s => Redirection
This class of status code indicates the client must take additional action to complete the request. Many of these status codes are used in URL redirection.
- 400s => Client errors
This class of status code is intended for situations in which the error seems to have been caused by the client.
- 500s => Server errors
Speak with Backend team…
Of-course, you need to be familiar with XML and JSON syntax and some other technologies to ensure a proper understanding.
Lets Speak Automation…
Below figure describes the main and most common tools and frameworks to automate your API test cases.
You can either choose a tool which comes with a UI for easier setup..etc or if you like terminals and writing code, then you can pick one of the Non GUI tools.
I like to separate automation tools from UI perspective; therefore, below figure will separate tools based on GUI and Non-GUI.
Let’s go through the tools and get some insights
RunScope: Runscope is a SaaS-based company that provides solutions for API performance testing, monitoring and debugging.
Amazing reporting and emails notifications as a personal note.
Postman: The most-used REST client worldwide; Designed from the ground up to support the API developer; Intuitive user interface to send requests, save responses, add tests, and create workflows.
SOAP UI: SoapUI is an open-source web service testing application for service-oriented architectures and representational state transfers. Its functionality covers web service inspection, invoking, development, simulation and mocking, functional testing, load and compliance testing.
Cypress: JavaScript e2e testing framework that’s Selenium free!
The beauty behind it is that Cypress solve the waiting problems in e2e automation testing and address it in a proper way through waiting automatically.
P.S: Cypress also includes a modern GUI as well
Codeception: The full stack testing framework that you can test all you App using it.
codeception is a PHP testing framework that works with Selenium for e2e tests and is a great choice for API as well.
Shell Script: My all time favorite to write API tests for the the simplicy and no complications for framework setup …etc
Run on command line directly and magic happens.
Conclusion:
APIs testing is the most important test you can perform as a QA Engineer; it gives you the required confidence to ensure that the server is responding in a proper way and reduce the testing efforts while performing e2e.
And always remember, 400s HTTP status isn’t always error!
References:
