Is UI Testing enough to assure the quality of a software? - API Testing... Where?? When?? Why??

I would like to begin this article with real statistics from google trends. If you see the below graph you will understand, how the trend of API testing increase with last few years. This shows the importance of API testing nowadays.

This doesn't mean we should do API testing for each and every software application, It's depends on the software development architecture.

To understand the importance of API testing and where it is applicable, we should have a basic idea of software architectures. In this article, I'm going to discuss two main architectures in very high level and considering microservice as an API.

• Monolithic Architecture.
• Microservice Architecture

Monolithic Architecture

Monolithic Architecture describes, a software application in which the user interface (presentation), functional process logic (business rules), and data access are combined into a single program from a single platform. - wikipedia.

In simple words, in monolithic architecture, front-end codes (eg:-javascript validations, html and css) and back-end codes (eg:-java code) bundled as a single package like "war" file and will be deployed in a server. For data access, there is a single database connected with back-end codes (database replication does not consider here). So all the developed software or its components can be accessible via UI only. So UI testing is enough for monolithic applications.

Microservice Architecture

Microservice Architecture (MSA) is a specialization and implementation approach for service-oriented architectures (SOA) used to build flexible, independently deployable software systems. As with SOA, services in a microservice architecture are processes that communicate with each other over a network in order to fulfil a goal. Also, like SOA, these services use technology-agnostic protocols. In a microservices architecture, services should have a small granularity and the protocols should be lightweight. A central microservices property that appears in multiple definitions is that services should be independently deployable.The benefit of distributing different responsibilities of the system into different smaller services is that it enhances the cohesion and decreases the coupling. This makes it easier to change and add functions and qualities to the system at any time. It also allows the architecture of an individual service to emerge through continuous refactoring, and hence reduces the need for a big up-front design and allows for releasing software early and continuously. Microservices are a kind of APIs -Wikipedia

In simple words, if you refer the above diagram for microservices, you can clearly identify three layers;

1. Presentation layer (UI).
2. Business logic layer (Microservices).
3. Database layer (separate database for each microservice).

Front-end(UI) codes and backend code(microservices) will be deployed separately in servers as separate packages. So, after the deployment, UI and the back-end microservices can be accessible separately and they can perform their respective functionalities independently. 

When executing the application Through UI, UI will call the microservices (1), microservices will contact the database [if data needed form the database or need to save data into the database] (2), then database will return the relevant information to the microservices (2), microservices will pass the information to UI (3).

At the same time, another application or UI can connect to the same microservice and can perform (a), (b), (c).

Moreover, a http client like POSTMAN can directly connect to the same microservice and perform (x), (y), (z). 

In above first and second example, the end user will be an application user (eg:-data entry operator), and he will not directly consume the microservice, but he will indirectly consume the microservices through UI. 

But in the third example, the end user will be a developer (can be in a different organization, like we are consuming google APIs) and he will directly consume the microservices. Since microservices are abstracted consumers/developer don’t have any idea what is happening when send a request to the server via microservices, they knows only the input and output. If you followed me in the correct direction, you can see here, the microservices behave like independent usual/traditional software. So microservices independently testable same as UI testing including validation and verification.

Since microservices are independently testable, we shouldn't wait to test the business logics till completion of UI design and implementation. So we can test the microservices earliest in the software development life cycle and fix the defects early as possible. This will reduce the chances to produce new defects after integrated with UI. 

Now let’s discuss why should do API testing, even though end users expected to use the UI, they can access and refer the API using browser developer tools like firebug (Firefox) and developer tool (Google Chrome). These tools expose almost all information about the APIs.

If you see the below two images, the first image shows the UI, and the second image shows the API call to the server when hit the register button. You can see the request URL, URI and body. If you refer the request body, it has data which we provide in the UI. Since We know all information about this API, we can register any number of users only usingAPI (without UI).

If we did only UI testing and didn’t do service level testing, we should face below mentioned issues:

1.   Data Inconsistency : If we take the same above images as example, For the email field there are validations in the UI, but don’t have any validation in the API. So, when we directly using APIs we can insert any characters to the email field in the database.

2.   Authentication & authorization violation : Just think there is a requirement like, only admin users can delete records. This requirement was achieved by disabling and enabling the delete button through UI, based on the user role, but there is no validations in API. So, anyone can delete any record by tracing the API calls relevant to the delete operation.

3.   Performance issues : Let’s say there is a requirement to show 10 records per page and when do pagination the next 10 records should show (overall there are thousands of records for the query). This can be achieved by getting all records using a single service call and can show 10 by 10, using front end logics. Nothing wrong with this implementation, but to retrieve thousands of records from the database by a API, should take some considerable time. This will lead to performance issues. If we implement a request parameter for no of records, we can avoid this kind of issues by getting small junk of records.

4.   Security issues : One of my previous project, there is a database, which is having all personal information of every individual including sensitive information. The requirement was when search a person’s name, system should show the address of the person in the UI. When we test through UI it works fine as expected, but when we test the API response, it has complete object of that person including sensitive information. If we release that application by only doing UI testing, anyone can see anyone’s personal information throw the API. It will be a huge security issue.

Finally, when we consecrate on automation for SOA and Microservice architecture applications, it's advisable to follow "Agile Test Automation Pyramid" as shown below;