Integration Testing - Hello, Newman

‍In recent years, there has been endless debate around microservice vs monolithic architecture. 

While there are still some good arguments for the monolithic architecture (for example, they may be simpler to deploy and debug) we can say with confidence that most companies, specifically SaaS-oriented companies, are now going with microservices architecture. 

At Anecdotes, we definitely see the major advantages here and have implemented the backend with a microservice architecture. In this short post, we’ll give you a behind-the-scenes look at how we did it and some thoughts we had along the way. To start, we created a service template, which is basically a connexion application running on top of Flask, that each Anecdotes service derives from. Each service exposes an OpenAPI specification that describes its endpoints and entities.

While it doesn’t matter in which architecture you choose, you will have to be able to test your application as one working application.This means that you will want to test the main (or all) flows in your system. These flows are usually complex and are composed of more than one request or action. Let me show you how we achieved this:
‍

‍Integration Tests Using Postman

Postman is a collaboration platform for API development. It's really an ecosystem composed of a client (Postman), a CLI tool (Newman) and a SaaS to share, collaborate and develop APIs. 

Among its features, Postman supports the OpenAPI spec, which means you can import your OpenAPI specification document and get a template for each of your endpoints. 

Using those templates, we built a Collection that will represent a flow in the system. Within this collection, we used Postman’s built-in features such as Pre-request Script and Tests to run actual JavaScript code before and after each request. This allows us to run actual tests against the responses.

Finally, we wrapped it all together by exporting these collections into JSON files. These JSON files are executed in the Anecdotes CI/CD pipeline using Newman CLI as a gated step, protecting against pushing code that could break our system. 
‍

{{banner-image}}

So What’s Next?

Using Postman/Newman created a few limitations that reduced our velocity and are  keeping us away from our goal of having 100% coverage in our integration tests. The first limitation is the capability to share context between requests (possible, but not so friendly) and collections (currently not possible). The second one is an easy way to share common functionality between collections and even requests.

We have started to develop a framework that will overcome those limitations and will do much more - it’ll let you declare a flow just by writing a single YAML file. We did this by following the DRY principle and used openapi-codegen to generate on-the-fly SDKs so all that is left for us to do is to connect the parts. But I’ll save that for our next blog post :)

‍