Is there really any difference in designing test cases for the API and the GUI for any product?

I am writing functional GUI test cases (CRUD feature) for my application. Can I use the same test cases for the API testing (mainly CRUD related test cases) or could there be some test cases which can only be executed using API testing?

  • 2
    How would you test client side validations through API? Commented Dec 3, 2019 at 21:42
  • Food for thought. Commented Dec 4, 2019 at 1:54
  • 1
    Ex. Save button gets enabled on editing any field value on page. Commented Dec 4, 2019 at 1:57
  • @VishalAggarwal As per my understanding, your example is client-side validation. It's not making any difference in server-side so there will not be any API validation. Commented Dec 4, 2019 at 4:55
  • Exactly Nitin, that's how I draw the line between API & UI tests. Commented Dec 4, 2019 at 19:22

5 Answers 5

  • The user interacts with the GUI
  • The GUI interacts with the API
  • The API interacts with the back end

In theory the GUI tests should cover all the API tests, right? Well, what about when the GUI prevents the user from submitting invalid data? You still need to test that the API handles these cases sensibly. Each layer should be tested separately:

  • GUI: Acceptance tests
  • API: Functional tests
  • Back end: Unit tests

These are not the only tests that exist. There are integration tests and more.

You should find that there is some overlap between each layer. Some GUI tests will not interact with the API, but some will and will execute the same code as in the API tests. The same for the back end tests. There will be some tests that can't (in theory) or are too difficult to be tested from the API, so need to be unit tested instead.

  • Nice try.....so if I execute all the test cases for GUI, then indirectly it will cover all the API & backend test? as it's(GUI) the top layer of the system. Commented Dec 4, 2019 at 6:20
  • 1
    @NitinRastogi I'm saying the opposite. That some things can't be tested just from the GUI. It's necessary to have API tests for those things, and back end tests for those things that can't be tested from the API, such as exception handling that is theoretically impossible, or at least is impossible to trigger from the API, such as the network going down just after the request was received.
    – CJ Dennis
    Commented Dec 4, 2019 at 6:23
  • Can you plz share some list of scenario( link or generic TC) which can be tested only using API? Commented Dec 4, 2019 at 6:27
  • 1
    @NitinRastogi I gave an example in the answer. The GUI has input validation, so a certain field can only be an integer. However, the GUI can be bypassed and the API used directly. What happens if someone passes text instead of an integer for that field? The GUI prevents you from testing this case, but it can still happen.
    – CJ Dennis
    Commented Dec 4, 2019 at 6:31
  • 1
    @NitinRastogi some more examples - GUI can show the user a list of items available for that user (one API call) and then show detailed data for one of these items (another API call that includes the ID of that item). I.e. access through the GUI always asks for details of a valid item. However, you need to test whether the API acts properly and gives an appropriate response if a nonexistent item ID is requested, or an item ID belonging to another user which this user shouldn't be able to see. You need to test inputs that are technically possible even if GUI won't/can't send them normally.
    – Peteris
    Commented Dec 5, 2019 at 0:06

Yes, API and GUI are different from a hardware product or command line enterprise software and as such requires specialized approach and techniques.

But GUIs and APIs are usually a very thin layer above the actual business logic and features, when designing a test you you obviously check that the GUI itself (colors or location of elements for example) or API (relevant fields have relevant values for example) works as expected, but we need to remember though that those have a purpose and they do not exist for the sole purpose of being there.

The color of a button or the value in a response field of an API deliver a message to the user, clicking a checkbox has more behind it than the visual part- it actually acts on some information and influence how the software works.

To summarize, GUI and API are only tools for testing the product specifications and do not stand by themselves.


Note: I will talk about testing itself since the documentation of certain activity is only but a product of the activity itself.

I'm not sure is your question is about "the testing for ... is different" or if the "the testing design for ... is different".

The second point talks about the heuristics for exploration, the "meta-hows". E.g., HICCUPPS:

  • History. We expect the present version of the system to be consistent with past versions of it.
  • Image. We expect the system to be consistent with an image that the organization wants to project, with its brand, or with its reputation.
  • Comparable Products. We expect the system to be consistent with systems that are in some way comparable. This includes other products in the same product line; competitive products, services, or systems; or products that are not in the same category but which process the same data; or alternative processes or algorithms.
  • Claims. We expect the system to be consistent with things important people say about it, whether in writing (references specifications, design documents, manuals, whiteboard sketches…) or in conversation (meetings, public announcements, lunchroom conversations…).
  • Users’ Desires. We believe that the system should be consistent with ideas about what reasonable users might want.
  • Product. We expect each element of the system (or product) to be consistent with comparable elements in the same system.
  • Purpose. We expect the system to be consistent with the explicit and implicit uses to which people might put it.
  • Statutes. We expect a system to be consistent with laws or regulations that are relevant to the product or its use.

The first point talks about the result of using the heuristics, the "concrete how", the exploration itself. And every context (and product) will have different outputs of heuristic application.


Usually for UI testing I'll focus on the major work flows/use cases. You mentioned the CRUD operations. I'll have a test for each of these to make sure it works. Typically you can black box test these imo. "If this UI goes out tonight, and these work flows pass, the UI should be good"

For API's i usually have 1 or multiple tests for each endpoint and verify the response is what is expected, and typically I grey or white box test this. "If this API goes out tonight and these end points behave as expected, the API should be good"


The main difference in designing the GUI and API test-cases is the parameters verified and its expected result

  • GUI test-cases mostly validate the user flow and test-cases will comprise of the Pre-requisite, Steps to perform and the expected results at the user end
  • On the contrary, API test-cases will include endpoint details, the C/R/U/D operation to be performed and the expected API responses

Many software testing companies prefer both GUI and API testing as in GUI testing, while validating a user flow, multiple APIs are called at the backend that communicates with each other. This communication between the APIs is difficult to test during API testing as endpoint of each API individually tested.

  • Multiple API interaction functional flow can also be captured in API tests by chaining requests which is still much more easier to develop & maintain compared to UI tests. Commented Dec 25, 2019 at 16:09
  • As a rule of thumb, any tests which can be covered on API layer , should not be developed on UI layer as it's expensive. Commented Dec 25, 2019 at 16:11

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.