Today I'd like to talk about the importance of API testing and explaining how the dominance of microservice architecture in modern services is forcing us to adapt to new QA requirements. An integral step in this adaptation is the ability to test a product without using a UI interface. It's not as difficult as may sound.
The Importance of API Testing
New and unknown things frighten us. But sometimes, if you dig deeper, everything turns out to be not as scary as it might have seemed. In this article, I will tell you why API testing is not difficult and how this skill will help you become a cool QA specialist.
When it comes to API testing in a team, a beginner QA specialist gets lost 一 even looking towards the server’s direction is scary, let alone sending requests to it. These concerns are justified. While testing the UI, you involuntarily become a user of the product and see the same graphical interface as a potential client. It is enough to enter the text in the required field of the browser, and you will receive an understandable error. When getting familiar with API, it may seem that it requires a different testing strategy. In fact, all you need is a little more technical knowledge:
- understanding client-server architecture;
- principles of the HTTP protocol;
- knowledge of JSON and XML data transfer formats.
And, of course, self-confidence.
Why Testing API
I'll help you figure out how to deal with the first three points, but to achieve the last one, you need to accept one simple thing: microservices rule the world. Monolithic architecture is slowly becoming a thing of the past. Today, all trendy and cloud solutions are created on a microservice architecture. In such a product, the UI may not be provided at all, and you will have to face backend testing.
In a monolith, the backend communicates with the frontend through the program code according to a single unchanged scheme. It's like playing table tennis with your partner 一 your roles are obvious. Microservices are different: each of them is a separate server with its own logic. One creates photos, the other processes them, the third one stores, the fourth transfers to the user. In this case, hitting the tennis ball is not enough. It becomes like baseball: first, you hit the ball, then run after it to catch it. Likewise, a microservice can be both a client and a server in relation to other "players".
Imagine there is a service that can apply filters to photos, and another one can store files. There are two options for their communication:
The service with filters goes to the photo storage, takes the required file, and paints the photo in sepia. Here, the filter service is the client and the store service is the server.
The storage service takes one of its photos and carries it to the service filter in order to determine which filter is applied to the photo. The service filter is as follows: "Dude, this is sepia." This is how the client and server are reversed.
To make microservices understand each other, they came up with an API (Application Programming Interface), a special software interface. Testing helps ensure that a program fulfills its intended purpose and can interact correctly with other programs. It is possible to validate and automate API tests even with a minimal theoretical base. The main thing is to find the right tools.
Stage 1: Shock
Imagine QA specialist John, who was told to test the functionality of the process of creating custom cards in the hospital software. The product does not have a UI, the data comes from a third-party system. That is, the service is tailored for one program to use another. Prior to that, John spent his entire career doing purely manual UI testing. So the first emotion he experiences at this testing stage is one of shock. There are no familiar buttons and fields in front of him.
Calm down, John. Here is the most common tool for API testing 一 Postman. The program allows us to issue a request in a form that is understandable to us and transmits it to the server in a language it understands. We will insert all further steps in Postman.
To request information from a server, you need the HTTP protocol, a hypertext transfer format in a client-server architecture. There are different types of requests. Sometimes the client wants to ask or send something to the server, sometimes to delete information from it. This is how HTTP request methods appeared. The most common are: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH. The method defines the action relative to the server.
So, we choose the path along which we will send the request:
What we want to tell the server is the request body. The item is optional. The key information for the server is displayed in the request transmission method. Returning to our example of an eHealth program, in the "Path" line we write the required link, and in the body we indicate information about the medical card: first name, last name, patient's age and diagnosis.
The header helps the server to decrypt the message correctly. Sometimes it is not associated with the request body or is absent at all. By specifying “Accept” in the header, we let the server know what data we are ready to receive in response. If you are satisfied with any information, the header should contain the value "* / *".
Sending…
Stage 2: Denial
Postman issued a set of text, quotes, commas, and other characters. John does not understand anything, he is angry. He experiences denial - so far he has little faith that something useful will come of it.
Fortunately, the HTTP protocol has a description of not only requests but also of server responses. 415 is a status code. The server indicates that it has received data that it cannot read. There are many status codes for different situations. The answer ‘200 OK’ is an indicator of a successful request. The 404 code is known to all Internet users and means that the resource was not found. So, I will not dwell on status codes. You can easily google them all.
What did John do wrong? Most likely, he did not think about the correct "packaging" of the document. JSON and XML are used for storing and transmitting data. These two are completely interchangeable formats. It is difficult to convey a large amount of information only through text. Of course, this could be done through text if the data were not read by the computer. It must know in advance the format and types of data, how to find them in the system, and work with them. You cannot send XML or JSON to all servers and think that you will be understood. The developers prescribe the format of the received data when creating the program.
John googled and found out that his server can communicate in JSON, so again he sends a request to the same address in the required format. Success! The server responded with another set of characters, but thanks to Postman, they can be translated.
So let’s sum up: the HTTP protocol defines the communication format between the client and the server. To send an HTTP request, you need special software (Postman, and you can also try Insomnia REST Client, HTTPie or another program from the list). The client, John, sends a message and receives an appropriate response. Communication with the server takes place in one of the formats - JSON / XML. The received data is decrypted by software.
Stage 3: Bargaining
To automate an API test, you need to master a programming language: Python, Java, C#, or whatever you like or need in the project. So tester John goes like: “Automation? Oh, I’d better not. I’ll need to write a ton of code. I can never do that. Let's limit by testing, okay? "
In fact, a few lines would be enough. To run a simple test, you just need to master a language base. You can also find libraries for writing HTTP requests. Anyway, learning the basics of programming will be a significant investment in your professional experience.
You shouldn't have to spare a few hours of your time to open your way to automation. It will be difficult at first, but I assure you that soon you will notice a huge leap in your technical development.
Stage 4: Acceptance
I no longer need to persuade John to understand the benefits of API testing and automation. In my team of 16 people, five are testing API web applications. I think this is a clear sign of the demand for these skills. Any site or application using modern technologies has a complex backend. With a high degree of probability, the developer will choose a microservice architecture for its implementation. Therefore, you cannot go further without the API test.
The secret is....that there is no secret
There is no magic. The approaches to testing the functionality of the UI, augmented reality, databases, API are usually the same. The strategies of thinking over the test cases and maintaining checklists are almost the same as the strategy in ordinary manual UI tests. For API testing, the hard skills described above and additional tools are needed.
When building your career as a QA professional, you get fewer offers on the market, if you don't know how to do something. You limit your opportunities and career chances. You won’t be included in the top-ranked projects. And this is where everyone wants to be, right? That’s what I’m talking about.
To master testing, you do not need to study theory for years. A few months of intensive practice is enough. To help you, I'll share my API testing cheat sheet, so you could look for useful materials here. Basic theory, tasks, tools, libraries, and frameworks - everything that will help you immerse yourself in the topic and continue learning on your own. Go for it!
Useful resources for further learning
Basic theory
API https://www.howtogeek.com/343877/what-is-an-api/
REST API https://restfulapi.net/
Comparing SOAP & REST
https://www.springboottutorial.com/rest-vs-soap-web-services
HTTP request structure
https://www.tutorialspoint.com/http/http_requests.htm
HTTP response structure
https://www.tutorialspoint.com/http/http_responses.htm
HTTP status codes
https://www.tutorialspoint.com/http/http_status_codes.htm
Client-server architecture
https://www.britannica.com/technology/client-server-architecture
Micro-server architecture
https://smartbear.com/solutions/microservices/
Microservices vs Monolith architecture
https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/
JSON description https://www.json.org/json-en.html
JSON vs XML https://www.w3schools.com/js/js_json_xml.asp
Tools
Postman alternatives https://www.pcstacks.com/postman-alternatives/
Traffic proxy
https://www.apriorit.com/dev-blog/591-proxies-for-application-testing
Fiddler
Burp Suite Community Edition
https://portswigger.net/burp/documentation/desktop/getting-started
JSON validator https://jsonlint.com/
XML validator https://xmllint.com/en
Notepad++ https://notepad-plus-plus.org/downloads/
Atom https://atom.io/
Courses
Codecademy https://www.codecademy.com
Free Code Camp https://www.freecodecamp.org
edX https://www.edx.org/course/subject/computer-science
Coursera https://www.coursera.org
Libraries and frameworks
Python + requests + pytest
https://www.ontestautomation.com/writing-tests-for-restful-apis-in-python-using-requests-part-1-basic-tests/
Java + REST Assured
https://techbeacon.com/app-dev-testing/how-perform-api-testing-rest-assured
C# + RestSharp
https://www.ontestautomation.com/restful-api-testing-in-csharp-with-restsharp/
Groovy + Spock
https://blog.j-labs.pl/2019/05/Test-your-REST-API-with-Spock-Introduction-to-Spock-Framework
Other
Practical exercises https://www.codewars.com/
Top comments (0)