A Journey in Automated API Tests (2 Part Series)
Testing can be time-consuming and a bit tedious. Many clients don't add automated testing to their contracts because it's too expensive or time-consuming. This comes with a trade-off that can heavily impact your product's quality and lifespan.
For the scope of this article, I'm going into the fundamentals of API testing and show you ways to easily integrate it with your existing and new CI pipelines.
Let's imagine you're about to ship your API to production. You already have API testing in mind but you're not quite sure how to embark from here. It's important to outline your tests while you are developing since it affects many choices you need to take during development. For instance, you'll need to figure out the best way to implement authentication and authorization that works reliably for your front-end app and during testing. If you are developing modern web apps, then JWT is a great way to add authentication to your project. You might also want to consider to use Swagger as a great tool to document your API. This documentation boosts your productivity while you outline your tests.
In this post, I'm going to use my homepage's API built on top of ASP.NET Core that I'm going to use for my homepage. It has authentication and a few routes that can fetch (everyone) and add (admins only) my published blog posts. Perfect for API testing.
Now, how are we going to test it? I'm using a tool like Insomnia to test my API during development time. I prefer it over Postman because it's lightweight and gets its job done, faster (and it looks beautiful).
What have I done here? I have a simple test path. I want to POST a new blog entry, GET all of them, and lastly DELETE the one I POSTed before.
What do we know? We know the ID that I use for my POST request. We can simply refer to it to DELETE the entry.
Okay cool, so far for development time. But what if you want to go live in production or staging, and test your API there? Surely you could simply use Insomnia again but you probably don't have enough time for that. Rather than, you might want to spend your time on additional development.
There are many tools available out there in the wild that can automatically test APIs as part of your CI pipeline. I stumbled upon Loadmill because it's simple to use similar to Insomnia and they have a free tier.
The migration from Insomnia to Loadmill is straight forward. Insomnia helps me to outline my test and I can map it over to Loadmill. We create a new Test Suite and a new Flow in there. Flows host multiple requests that are fired one-by-one automatically, similar to what you perform manually while testing.
Before I create any requests, it's advised to check your parameters and store all variables that you will need for most requests. I know that I'm going to need a base URL of the API and a valid JWT token to perform certain POST and DELETE requests.
After that, let's create a Flow that automatically tests our blog posts API controller like in the screenshot of Insomnia above that we can use as a great lookup. I need to provide the URL, the body, and the required headers.
For the POST request, I stored the blog post ID in a dedicated parameter that I can use for future requests, like the DELETE request. It's also great that I can perform XPath for my responses in both Insomnia and Loadmill. XPath allows us to extract values from JSON or XML and store them as parameters for consecutive requests.
Now, let's GET all stored blog posts.
Simple, ain't it? We don't need to pass a bearer token or anything. We just want to get it all. In the Advanced options, we can add basic validation - like timeout - and post-processing. Quite handy.
Lastly, let's delete our new blog entry as part of our test path.
Here, we need to pass the auth token again, but that's simple and doesn't require further explanation.
Cool, now let's hit that shiny Run Suite button in the top right corner and jump into surprises.
If you're feeling lucky, your test will pass without any issues. We can look into details of individual Flows and as we can see, it passed all tests. 🎉
That was straight forward, wasn't it? I hope I could offer a glimpse look at automated testing and encourage that you don't skip them for your projects because it's that easy.
I hope that you've enjoyed my first submission on dev.to. Please let me know what you think. You can also check me out on Medium for previous (and future) posts.
Cover image by Viktor Jakovlev