UI test is the most common type of testing; also, the number one QA engineers love to program. They focus on testing an application user interface to ensure that its functionality is correct.
Did you know that SoapUI can be used to perform functional tests and basic tests focused on the load?
UI tests imitate the end user. Therefore, these scripts perform all the tasks a person would do on the front end. That typically involves:
- Loading screens/pages
- Writing/reading a bunch of fields or elements, including lots of waits all around.
On the other hand, API testing focuses on verifying that the interactions of many small components can integrate without issue (check the application meet the expectations of functionality, reliability, performance, and security). Since API tests bypass the user interface, they tend to be quicker and much more reliable than UI tests.
According to UI automated tests, scripting all these actions, even with a highly reusable framework, takes some time. Maintaining UI tests is even more difficult. Since the code base is many times bigger than API level tests, for instance, it becomes costly to maintain too.
Many times, without notice, we find ourselves testing the API through the UI. For example, the very common “login test”: A login action on the UI, is always looking for a search (POST). If we decide to do it straight to the API, the process is faster. We can lose a lot of time trying to test actions in the API because we are testing in the wrong place.
After saying all that, my advice is to test as much as you can with API testing. 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 and PUT tests, a 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 response body 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 tested all the scenarios, you can think of with API testing. Then it’s time to think about UI testing. Most of all is about verify and check the elements on it. For example, thereś a page with a form to the field and also has a cancel button; a cancel button cannot be tested with an API test. Another example is an error message that appears to the user once you complete the form. You have to do a UI test to check if this error is displayed.
Considering testing the API first could save us a lot of time and help us be more precise in our results.
Did you know that SoapUI can be used to perform functional tests and basic tests focused on the load?.
