Why we built Dokkimi

The testing gap

If you run microservices, you’ve probably felt this: your unit tests pass, your staging deploy looks fine, and then production breaks because service A sends a field that service B doesn’t expect.

Unit tests are great for isolated logic. But the moment you mock the HTTP client, the database, or the message queue, you’re no longer testing the thing that breaks in production — the integration between services.

Staging doesn’t fix this

The usual answer is “test it in staging.” But staging environments have their own problems:

• Shared state. Two developers testing at the same time step on each other’s data.
• Drift. Staging is never quite the same as production. Different config, stale data, missing services.
• Slow feedback. Deploying to staging takes minutes. Getting a clean environment takes longer.

You end up with a testing strategy that’s fast but fake (unit tests) or real but slow and flaky (staging).

What if you could have both?

That’s the idea behind Dokkimi. For each test run, Dokkimi spins up an isolated Kubernetes namespace with your actual services, real databases, and a traffic interceptor that captures every HTTP call between them.

You write assertions against real traffic - “when I POST to the API gateway, verify that the order service called the payment service with the right amount.” No mocks of your own code. No shared state. No drift.

assertions:
  - target: httpCall
    match:
      origin: order-service
      method: POST
      url: payment-service/v1/charges
    assertions:
      - type: request.body
        path: $.amount
        operator: eq
        value: 1998

How it works in practice

1. You define your services, databases, and mocks in YAML files under .dokkimi/.
2. dokkimi run deploys everything into a fresh namespace with sidecar interceptors.
3. Your test steps execute — HTTP requests, database queries, delays — and the interceptor logs all inter-service traffic.
4. Assertions run against that traffic. You can assert on request bodies, response codes, headers, and even console logs.
5. Everything is torn down automatically.

The whole cycle takes seconds for small topologies. You get production-like confidence with unit-test-like speed.

What Dokkimi is not

Dokkimi is not a replacement for unit tests. You should still test your business logic in isolation. Dokkimi fills the gap between unit tests and production — the integration layer where services talk to each other, databases get queried, and external APIs get called.

It’s also not a load testing tool or a monitoring solution. It’s specifically for functional correctness of multi-service workflows.

Try it

npm install -g dokkimi
dokkimi init
dokkimi run

The init command scaffolds example definitions so you can see the structure before writing your own. Check out the docs for the full reference.