In my previous post, I shared a way to hide technical boilerplate and make REST API calls more expressive within your integration tests. To further improve your tests, you also need a strategy for handling integrations with the “outside world.”
This post describes how our team at Allegro started building a new service. We’ll go through the process step by step: first ensuring we have a clear understanding of the business process to implement, then choosing the service name, and finally setting up the project structure. By the end, you’ll see how to create a solid application skeleton that makes developing subsequent features straightforward and efficient.
Integration with external services, regardless of their type, is the backbone of modern microservices architecture. The era of huge monolithic applications with a single database is over. Today, implementing even a small business process requires cooperation with other services.
Have you ever struggled to identify which REST API is being tested in your integration tests? In this article, you’ll learn a clean and readable way to call REST APIs within your integration tests. The goal is to make the WHEN section of the test clearly show which API is called and in what context, while hiding all technical details.
The purpose of this article is to present how to design, test, and monitor a REST service client. The article includes a repository with clients written in Kotlin using various technologies such as WebClient, RestClient, Ktor Client, Retrofit. It demonstrates how to send and retrieve data from an external service, add a cache layer, and parse the received response into domain objects.
