API Testing – Getting Started

In many ways APIs are the glue of the internet. The modern internet is increasingly built on distributed architectures and companies want to make their platforms extensible. APIs are a crucial part of these kind of business strategies. (If you aren’t sure about API terminology, check out my API testing glossary here).  APIs are also challenging to design and test. By their very nature they are meant to be accessed programmatically and to expose underlying constructs in ways that are simple to use and understand. You might be comfortable with how to test manually or even with various types of test automation, but not really know and understand how to effectively test an API.

I have been working on testing APIs for a while now and have also put together a course that I hope will help people looking to get started with API testing.  I also want to share some material for this on my blog in the hope that I can help others along this path towards API testing skills.

Let’s start with trying to understand a bit about web services. Many web services provide APIs that can be used to drive them and so understanding a bit about what is meant by the term web services is as a good a place as any to start with in API testing. As with any term in technology, it can take on different nuances for different companies and contexts but I find that a helpful way to think about it is actually in terms of mathematical functions. Don’t worry though, no complex math is needed to understand this.

When I was first introduced to functions in grade school I learned to think of them as a black box that took in some inputs and did some kind of transformation on those inputs to then produce an output. I use this same model to think of a web service.

Let’s make it concrete and look at a real life example. Let’s say we are testing an application and we want to get a first and last name to use for a login test.  We don’t want to use the same name every time, but we still want to have somewhat realistic names.  We could find a database of names and write some code that randomly selects names from it, or we could go to a service like uinames.com and get it to generate the name. By giving the service certain inputs (like an API path and perhaps some other request parameters), we can get back a user name that we can use.

We don’t know anything about how that service does what it does. It might use python, or php or javascript to do this work. It might get the names from a database, or it might request them from other services. We don’t know. We can just think of it as a black box that will give us back certain inputs based on the inputs we give. And that’s really all we need to know at this point. This is how I think of a web service. A black box that does some action(s) for you based on the inputs you give it and then gives you an input. In this way of thinking, APIs are the way we get inputs into the service and how the service gives us back the responses it has for us.

I want to start a bit of a series on API testing where we think of it this way.  We could call this black box API testing if we really want to give a name to it. I think it is an important part of interacting with and testing the modern web and I hope you find this that this series helps you along your API testing journey.