In our modern world, being always connected and getting real-time updates has become an important part of our lives. On-demand delivery is not an exception to this rule. We all, at some point, have bought something and then found ourselves refreshing the tracking link like there’s no tomorrow.
Our in-house apps use websocket connections in order to have real-time updates.
However, we also have clients that want to integrate with us directly through our API, and we offer a different solution for this.
So, how do they receive package updates in real time?
Webhooks to the rescue!
Before we move on, what exactly is a webhook?
A webhook (also called a web callback or HTTP push API) is a way for an app to provide other applications with real-time information. Unlike other APIs, where you’d need to poll for data very frequently, a webhook “pushes” data to other applications as events happen, meaning they get informed immediately.
Any API integrator can benefit from Stuart webhooks.
How can a client use Stuart webhooks
Every time there’s a relevant update on a package, we send a webhook to the clients that have them configured.
Some relevant updates might be:
- A client has requested a package;
- A courier has accepted a package;
- A courier assigned to any of your requested packages has changed their position;
- The package has been canceled.
And so on.
That gives the client integrated with Stuart the flexibility to build their own tracking mechanisms. For example, a webhook can trigger an SMS service to send the end customer a message when the courier picks up the package.
How we manually test webhooks
Let’s assume that we want to test that the api sends a webhook indicating that a package has been created.
We are going to test the following:
- The client configures the webhook;
- The client creates a package;
- The client receives a webhook.
We use a request bin server to receive the test webhook messages.
A request bin is some service that collects received requests and let us inspect them afterwards in a human friendly way. In this way, we manually create a package and check there that a webhook is received with a certain payload.
From a test automation perspective, it should work quite similarly. Our test suite will be the one creating the package but then we’re still don’t have the request bin under our full control.
So, we create request bins on demand via an API and then we can retrieve all the received requests via the same API.
Our e2e tests setup for CI
We have a dockerized environment were we have all services needed in order to have an up and running stuart-api. To keep it simple and focused on the problem we’re trying to solve, let’s assume that this is our setup:
The e2etests container is a java Maven project that uses RestAssured. Webhooks will be sent by a background worker process running in our API service.
How we solved it
After digging into it and evaluating some things (like creating our own rest service that will work as a “headless” requestbin), we found a nicer solution.
Before every test execution the steps to follow will be:
- Create a new bin;
- Update the client we use to create packages so it has the webhook URL as that created bin;
- Create a package with that client;
- Poll the request bin until messages are received;
Have you ever faced the same challenge of testing webhooks as we did? Have you done it in a different way? Do you like our solution? I’ll be really happy to listen your feedback!