The Two Side Of API Testing (And Why You’re Probaly Focusing On The Wrong One)

As a test automation engineer, you know that APIs are a crucial part of modern software development, and that and API testing is all the rage. But did you know that there are not one, but two distinct ways you can use APIs in your test automation efforts?

Hear me out.

First of all, you can test the API itself. This is what most folks think of as API testig. This includes verifying the payloads, response codes, and error conditions.

Now don’t get me wrong: this stuff is important.

But it should only really be the first level of API testing. And ideally, you’ll want this to be an integral part of the development process (i.e. done by or in conjunction with the developers), NOT as a separate testing activity.

(Read that last paragraph again — if you are doing API testing outside the development build cycle, your feedback loops are probably too slow.)

In my experience, the real power of API testing lies elsewhere. In using APIs to test actual business functionality.

You see, by interacting with the API, you can automate user journeys and end-to-end scenarios more efficiently and effectively than if you were relying solely on UI testing.

And this can lead to faster and more reliable test automation results, AND tests that are ultimately easier to write and to scale.

What sort of API testing do you do?