2

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?

Improve this question
0

4 Answers 4

Reset to default
4

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.

Improve this answer
1

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.

Improve this answer
1

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
Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.