How to decide Test Cases for API vs GUI Automation

Question

Please help me understand, if I am trying to implement Test Pyramid and have automated good amount of API tests, how do I decide what all needs to be automated using the GUI now and what all can be skipped ?

Thanks

Answer 1

I would suggest starting by understanding what logic & functionality is implemented in the backend (API). Then start writing tests for API which will check this logic and functionalities implemented.

Only then I would be adding GUI tests.

Example: Web application with Rest API, calendar which you can export to Excel and download. API is preparing excel and make it available to download.

I would start with API testing:

1. Sending http requests to create few meetings for current week
2. Sending http request to prepare download link with excel
3. Sending http request to download excel file from previous request
4. And then try to think about other test scenarios for this API

After doing that kind of tests, I would prepare one scenario for GUI: clicking on button "Download calendar as Excel file" and checking if browser downloads that.

Answer 2

The typical modern web apps are pretty well separated:

• Frontend apps (Ember, React, etc...)
• One or more services (Python, Java, etc...)

Risk based testing can be apply with each component in isolation: You sent HTTP requests to test the services and mock network interaction on tests of the frontend component.

These component tests will encompass basically all "test cases". Since the components have different goals, it is easy to explore only those. E.g., you don't check CSS color calculation on API tests and you don't check for SQL Injection on the frontend (unless it is checked there).

With the components tests, you can focus on checking integration:

• With contract testing, you check if the needs of the Frontend app are satisfied by the Services.
• With end-to-end tests (Selenium, e.g.), you validate the building on each enviorment. This are not meant to check if the app handles the user interaction themselves but that the app is properly deployed. It will be even more superficial than Smoke Tests, because those check the behavior of the app itself.