Originally posted: https://www.dowen.me.uk/Automated-rest-api-testing-with-python/
Last time out I introduced you to the start of my journey to automate all the "test" things in Python. I continue that journey now by switching focus away from frontend, to Restful Web APIs. You can look back at my last post here.
Before you can make requests and you need to understand the API your testing. For this I recommend using a Rest Client. While you may already have mad skills in cURL, for the rest of us I suggest using Postman, Insomnia or SoapUI.
If, like me, you want to develop your API testing skills in a safe place, outside of any work projects, there are some great options!
Start your exploration using API documentation. For Restful booker, you can find that here.
Inspired by the article API Integration in Python – Part 1, I started by making a Python client to abstract interactions with the Restful Booker API. The article is not focused on testing, but instead shows us how to Constructing an API Library, using Requests.
This pattern of abstraction is great and we can use it along side an assertion framework to do some robust testing.
You can take a closer look at my API Library for Restful Booker, and my rest code on the Pybooker GitHub Repository.
This basic example makes a GET request to the URL https://restful-booker.herokuapp.com/booking/1/, and prints the resulting JSON response body into the Python console. Running it gives us:
Because the method returns the response object, we can not only get the JSON body, but also useful information like the HTTP Status code.
Requests can make use of a wide range of HTTP methods, explore it and see what you can do!
OK so now we can make Requests, and access the returned response in an object. With this, we can start implementing some automated checks, to see if we are getting back what we expect.
While you can assert on almost every aspect of the response, the most basic check is the response returned 'OK'. This means we made a valid request, and the service didn't throw an internal server error.
One step further would be to assert on the HTTP Status code. For example for a GET you expect to succeed you might expect "200 Success", and for creating a new item with POST you might expect "201 Created".