Why should I check the server response by using a GET call through an API if I already have a button on the site with the functionality to call the same method?
So you know where any problems originate
If you have an API that's retrieving information and a website that displays it, you test the API to make sure that the correct information is retrieved. Then you test the website to make sure the information is displayed properly.
Say you're looking for products in a category. Let's say the category is "hair care products", and you'd expect to see shampoo, conditioner, hair ties, hair clips, and the like. If you test the web site, and get pet shampoo, carpet shampoo, or car shampoo in the list of products that comes back, you don't know whether the problem is with the website asking for "shampoo" rather than "hair care products" or with the API (or with the database). You have to check what exactly was requested and then trace the API response to the request before you can work out what was wrong.
If you started with the API request and got the products you expected, then you'd know as soon as you performed the web test that the problem was with the website. If you started with the API request and didn't get the products you expected, then you'd know the problem was with the product categorization or the API. You could make a call to retrieve all products and check their categories to determine the source of the problem.
Adding to @Kate Paulk excelent answer using her example. A few more examples where bugs can be hidden or cause performance issues:
Pre fetching of information to be used in filtering (you ask for all possible product types and then filter them locally, trading loading speed for responsiveness) can be done wrong
Telemetry data can be wrong, contain sensitive information or be bloated for no reason
Bugs "canceling each other", for example you ask for hair products, get cat nail grooming products but print a hard coded list of hair products that was used for debugging
On top of that using APIs directly allows you more flexibility mimicking different behaviors, delays or anvironments.
Speed and Stability
Relying on UI tests to test APIs will quickly lead to a lot of problems.
It's ok for 1 test perhaps, but once you start to add more, a lot of problems arise.
Here's why you should avoid the UI when testing APIs:
- UI tests are slow
- UI tests will not show API level error codes
- UI tests require browsers (even if headless)
- UI tests are unstable and will occasionally fail
- UI tests increase the feedback time to developers
- UI tests require the code be deployed to an environment
- UI tests are brittle because UI changes can affect the API call being made
- UI tests will reveal UI problems unrelated to the API but affecting the use of it
That's why we did it in our project:
Our Story: We recently migrated an complex front end application from angularJS to angular 8 while utilizing the same API for data plumbing with little changes in geographically distributed sub-teams.
It helped us testing components directly to isolate & resolve issues quickly by putting issues in right buckets of front end vs. back end vs. services otherwise testing would have been very messy, time consuming & expensive through UI.