UI Testing Vs API Testing

UI testing:

UI stands for User Interface. UI allows the user to interact with the application.

UI testing refers to testing graphical user interfaces, such as how user interacts with the application, testing application elements like fonts, layouts, buttons, images, colors, etc. Basically, UI testing concentrates on the look-and-feel of an application.

UI testing is testing between users (humans in most cases) and front end or client side (presentation logic) of the application such as a browser.

For example, if you are testing an address book, the most likely scenario for a user would be adding in a new address. You could create a UI test that would navigate to the address book, click a button to add a new address, add the address, save it, and then search the address book to verify that it has been saved.

Now that your most common user story has been added, you have probably touched a number of the elements that you would want to verify in your UI. Next, think about other elements on the page that you might want to check. For instance, there may be a cancel button on the page where you are adding a new address. A cancel button cannot be tested with an API test; therefore, you should add in a UI test for it. Another example would be an error message that appears to the user; you may want to add in a test where you try to add an invalid address, and verify that the correct error message is displayed.

API testing:

API is an acronym for Application Programming Interface. API enables communication between two separate software systems. A software system implementing an API contains functions/sub-routines which can be executed by another software system.

API testing is checking API of a Software System. In order to check the API , it needs to be called from the calling software . Necessary test environment, database, server, application setup needs to be prepared before doing API Testing.

API testing is focused on the functionality of the business logic (such as a calculating total price) and it is entirely different from UI testing. It mainly concentrates on the business logic layer of the software architecture. This testing won’t concentrate on the look and feel of an application.

API testing is testing between backend or server side of the application and backend of another application.

Take a look at all of your possible endpoints and create a suite of tests for each. Be sure to test both the happy path and the possible error paths. On every test, assert that you are getting the correct response code. For GET requests, assert that you receive the correct results. If there are filtering parameters you can pass in with the request, be sure to test scenarios with and without those parameters. For POST, PUT, and PATCH tests, test that the changes you made have been written to the database; you can do this with a GET. Be sure to test scenarios where you are entering invalid data; assert that any message returned in the body of the response is the correct message. For DELETE requests, test that the resource has been deleted from the database; this can be verified with a GET.

Once you have tests that verify all of the important elements on your page, you can stop writing UI tests. It’s not necessary to create lots of scenarios where each field is validated for various incorrect entries, because a) you already created those scenarios in your API tests) you already have one UI test that verifies that the error message is displayed.

If you already have an automated suite of UI tests, it may be a good idea to take a look at your tests and see which scenarios could be covered by API testing. Converting your UI tests to API tests will make your regression suites faster and more reliable!