It is usual for a tester/SDET to come across the question and discussion around API Testing versus UI Testing, asking which is better or more important. More questions which one might cross on the same topic are as below:
- Which testing helps the tester to find more bugs and faster -- API Testing or UI Testing?
- Which testing is quicker and effective -- API Testing or UI Testing?
- Which testing is less flaky -- API Testing or UI Testing?
- Which testing helps to find risks and problems early in the development cycle -- API Testing or UI Testing?
- Which testing has less dependency and maintenance comparatively -- API Testing or UI Testing?
- Which testing provides quicker feedback on the health of product -- API Testing or UI Testing?
- Which testing needs little efforts and investment to build, execute and maintain -- API Testing or UI Testing?
- A tester can start testing with API before the UI is available, so which testing is effective -- API Testing or UI Testing?
- If API Testing is covered no need for UI Testing?
- Which tests cases while programming is in progress or yet to start -- API Testing or UI Testing?
- The APIs can be used to test web application service logic, so which testing is effective -- API Testing or UI Testing?
- UI affects the UX, so UI Testing is required; don't the API affect the UX? If both affect the UX, which testing is of priority and more influential?
- The testing of a system for data using API is possible before the UI is available, so which testing is effective -- API Testing or UI Testing?
- One can say it is functional just by using API with no UI, so which testing is effective -- API Testing or UI Testing?
- API Testing can reveal more details of services and web application server, which UI testing cannot with or without load balancers, so which testing is effective -- API Testing or UI Testing?
I hope that was not a big list of questions, and this list keeps growing if I share what I have come across as part of the reasoning. Probably, you might as well have witnessed such questions when discussing the API Testing over UI Testing.
The word "Testing" is vague!
I learn the word "Testing" is vague when used with no precise context and expectation. For example, "API Testing" does tell that subject of discussion and work is around API in one's testing. Also, it does not communicate precisely -- what in the testing of APIs. The same is for the testing of UI.
In most of our discussion, we see such words loosely said in conversation. As a result, it may lead to ineffective thoughts. For example, "Is API Testing important than UI Testing?". To me, this question does not tell -- What to provide as a response, so one can think about it and decide? On what basis the comparison is made for the effectiveness and in which context?
We can test API and UI for quality criteria as -- Functional, Performance, UX, Security, Accessibility, Simplicity, Usability, and more. Yes, we can test the APIs for UX.
How can one reduce the vagueness when the words become too casual?
When used the word "testing" providing the context of expectation, it can reduce the vagueness in communication. For example, "Testing for the API functionality is important than the functionality of UI?" Now you see the difference and clarity with this question in comparison to -- "Is API Testing important than UI Testing?"
API and UI are individual operating entities in a System
To benefit the reader here, let me take Mercedes-Benz's car assembly line illustration. What can relate to APIs and UI here? Can the exterior of the car be seen as UI and internal as multiple APIs which take the input and respond for movement of the car?
So the question here is:
- Testing of functionality just for the internals of a car is enough?
- By doing so, there is no need to test for the exterior (UI) of the car?
- If yes, why would skilled people work in designing and testing the UI that is exterior of a car, constructing various scenarios?
- Testing for the security of a car internal is sufficient? Should the UI of also of a car be subjected to security tests? Ask the same for performance, functionality, and UX.
I have heard there OTA updates for the software installed in a car. This software can control the internal and external of a car is what I see.
I learn the API and UI are two individual entities of a system. Testing of one entity will not overrule the need for testing of other entities. Instead, it can complement and help testing better. If thinking testing of API is enough and no need to test UI, then asking what tests look repetitive is logical.
Why would people invest so much money, time, and resources in building the interactive UI? Why the world faces the problem with fragmentation in each segment? Having the engineering focus on the API segment alone is enough?
Why we usually have two teams working on APIs and front-end? Why each of these teams are specialized and skilled in working at their areas and not in both? If testing for API is sufficient, why there is a dedicated team for programming the front-end and its testing? Answering these questions can arrive one at having a clarity.
Should the client be seen as UI?
What is UI in this context? The client end of the system will have code for:
- UI
- Rendering of UI based on context
- Processing the input
- Processing the output
- Processing and interacting with peripherals and its event
- And much more
To imagine the client's complexity, look at the exterior of your mobile phone device and how it interacts with internals for the input you provide. Think about the Push Notification you receive via an API and how it appears as UI in the notification tray. How acting upon the push notification in UI will respond? It looks simple case but not so when it comes to the handling of UI.
Seeing the client as UI and an endpoint to input the data and display is reasonable. But confining only to that will blind one. What was the need for the Developer Tool in a browser, if the API testing was sufficient? Every piece i.e. each entity in the software system is complex. Testing of one will not override the need for the other entity.
UI fails as hard as the API
I have been working on the server end and as well client end. I have experienced API functioning well but the client fails though it abides by contract. Should the client be seen as just UI?
The attributes of API will connect and communicate with the attributes of UI. If the API is functional and it does what is expected does not mean the client will be functional. The API is secure does not mean the client is secure. The API (service) is doing better in performance does not mean the client is also performing well. The UX can be annoying by the API while the UX of the client is well received. The context in which API is tested in isolation is different from the testing of a client.
To share one experience of me, the user entered the insurance details as in the insurance card. The API internally did handle the details differently in the presentation. As a result, the next time when API responded with insurance detail, the client crashed. It was the same data but presented in a different way which the client did not accept or understand. But when tested the API in isolation, API accepted the data in both formats. Then the business wanted the detail as expected by the client and not how the API presented it. Could the testing of API alone help me to learn the problem at the client end here? The API was vulnerable but not the client in one case. I used the API as an entry point for the attack. Eventually, the impact was reflected in UI with the response.
I have more such examples from my experiences, to say API and UI are two different entities. Testing for one in any quality criteria will not override the need for testing of the other. But it helps me to plan and design my tests well knowing them individually and how both interact.
How to respond for -- API Testing or UI Testing?
- Both are distinct, important, and needed
- Testing of each provide unique information and value
- Ask details for what to test and what is expected out of testing
- Rephrase the question asked to better one which is explicit with clarity
- Myths:
- Testing for API is important than testing for client
- Testing for API is sufficient and no need to test for client
- Testing for API will cover data which client do not cover
- As the automation pyramid talks of Unit, Integration (API) and UI layers, it is confused the client is UI layer. UI is one part of the client and not the whole.
- Testing for API finds unique information which may or may not be found by testing client
- Identify what to test in these two distinct layers
- Both of these layers have their own state and behaviorial differences
- So trying to mock with stubs on other layer be it from API or from client, may always have something critical unlearned
- When testing in this way, usually the focus is one element of a software and so it is called Unit Testing
- Testing for the APIs and testing for the client have distinct weight and importance
