🌎 Webhook Testing At Stuart

Keeping it real, with real-time updates

In our modern world, being always connected and getting real-time updates has become an important part of our lives. On-demand delivery is no exception to this rule. At some point, we all bought something and then found ourselves refreshing the tracking link, thinking there was no tomorrow.

We at Stuart have several solutions for that. Businesses can keep up to date through our Dashboard web app and Client mobile apps for Android and iOS. End customers have a tracking page, too.

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:

1. The client configures the webhook;
2. The client creates a package;
3. 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.

Personally, my favourite request bins are webhook.site and requestbin.io, but there are quite a lot of alternatives available.

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.

Earlier, we mentioned using the requestbin API to let us create bins and retrieve all messages. In the end, we can handle this with something as easy as adding a new service in our dockerized setup:

requestbin:
  image: our.docker.registry.com/requestbin
  networks:
    - e2e

Before every test execution the steps to follow will be:

1. Create a new bin;
2. Update the client we use to create packages so it has the webhook URL as that created bin;
3. Create a package with that client;
4. Poll the request bin until messages are received;
5. 💃

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!

…like what you see? Join us, we’re looking for a new buddy and hiring a lot of other profiles. 🚀