If you were to guess the importance of various types of automated tests by looking at the number of tutorials and articles about them on the Web, you’d think that UI tests were the most important. But this is not the case- so much of an application can be tested through other means, especially API tests. API tests are faster and much less flaky than UI tests, and they’re easier to write as well! Below are four types of tests that are better suited for API testing.
Login Tests: It’s easy to cycle through all kinds of username and password combinations with API tests. The response time from a POST to a login endpoint is lightning fast, as opposed to a UI test which has to wait for the username and password fields to be populated and wait for the login response to reach the browser. To prove this, I created a Postman collection that had sixteen login tests with various user and password combinations. The sixteen tests ran in less than three seconds! Imagine how long the equivalent UI tests would take.
However, you should have two automated UI tests: one that validates that the login page looks correct, and that the user is able to log in, and one that validates that an appropriate error message is displayed when the user attempts to log in with bad credentials.
CRUD Tests: When you’re testing CRUD functionality, you’re testing how your application interacts with the underlying data store. This is best done at the API level. It’s easy to create GET, POST, PUT, and DELETE tests using a tool like Postman. You can assert on both the response codes and the body of the response (if any), and you can also do GETs to assert that your POSTs, PUTs, and DELETEs have saved correctly to the database.
The only UI tests you need in this area are one that demonstrates that form fields can be filled out and submitted, and one that shows that data is displayed correctly on the page.
Negative Tests: API testing is great for negative tests, because not only can you run through all kinds of negative scenarios very quickly, but you can also run tests that aren’t possible in the UI. For example, let’s say that your form has a required field. In the UI, you can’t do a test where you submit a new record without that required field, because the UI simply won’t let you. But in the API, you can do a POST without the required field and verify that you are getting a 400-level response. API testing is also great for checking application security, because malicious users are likely to try to attack the application at this level.
Here is just a sampling of the types of negative tests you can run with API testing:
- sending in an inaccurate URL
- trying a request without appropriate authentication
- testing for IDOR
- sending in incorrect headers
- sending in a request without a required field
- trying a request with a field value that violates type or length constraints
- verifying that the correct 400-level error is displayed when a request is invalid
For UI testing, you’ll simply want to verify that appropriate errors are displayed on the page when you leave a required field blank or violate a field constraint. Everything else can be covered by API tests.
Tests of Complicated Business Logic: If you have an area of your application that requires an extensive setup of data and complicated business logic, it’s much easier to test with an API than with the UI. Consider my hypothetical Superball Sorter, which sorts balls of various colors and sizes among four children. Setting up the rules through the UI in an automated test would be tedious; assuming each child had a dropdown picker for size and color, you’d need to do a lot of element selection. But if the Superball Sorter had an API that could set all the rules for the children in a single POST, it would take milliseconds to prepare the test.
Similarly, after the sorting has been run, a UI test would need to grab all the responses on the page to validate that the balls have been sorted correctly, where an API could do a GET request for each child and validate that the appropriate balls are returned. Four GET requests will most likely be returned and validated before a UI test could validate a single child’s values.
Now that you have seen the many ways that API tests can be used, I hope that you will take the time to look at your current UI test suite to see which tests could be shifted to API testing. Your automation suite will be faster, more reliable, and easier to maintain as a result!
This comment has been removed by the author.
Thanks for sharing with us. Such a nice approach.
It's always welcome to push your tests as far down the test level as possible. If there's an UI test which can be performed as API test, go for it instead.
I'm glad you enjoyed this post, Marlon!
Thanks for sharing this. Taking tests to API level seems like a great idea
I'm glad you enjoyed it, Kolapo!