“Our UI Tests Hit the APIs”
This is a true statement. It’s always true when you are doing things such as testing native mobile applications, for example. The problem is that it implies something that isn’t true. It implies that APIs are then being tested, which is not the case. The APIs are being triggered and running, but that is not a test. There is a big difference between being in class during roll call, versus passing a test. APIs are websites & apps without UIs. They are direct links to the data and information, and therefore can have many paths to functional failure that are too often missed when only UI tests are done. We find this topic to be super interesting and important, and so let’s look into a real world example we recently encountered involving a food delivery application:
Now here is an example of where problems can (and do) occur…
Did you notice anything wrong with the payload?
There are three errors in that JSON response, and it’s unlikely
any of them would be caught by an Appium test.
APIs are data. Data requires a different concept when it comes to testing, but not a complicated one. All information should be formatted correctly, accurate, within expected ranges, and as per what the original API designs were. Testing UI is imperative to delivering quality features and products, but ignoring the APIs that power those UIs with data and information is like only looking at the cover of a book before publishing.
Open the book and do some detailed proofreading with API Fortress.