How do I test a NATS subscriber without a server?

Record your application once against a real nats-server with Keploy. It captures the delivered messages and their subjects, then replays them in order during tests — with no server and no delivery timeout.

Can Keploy make NATS tests less flaky?

Yes, because replay removes the asynchrony. Recorded deliveries are served in the order captured, so there is no polling, no timeout to tune, and no queue group race — the same code produces the same result every run.

Does Keploy capture NATS request-reply exchanges?

Yes. The request subject, the reply-to inbox, and the responder's actual reply are all recorded, so a subject mismatch or a missing responder shows up as a diff instead of a production timeout.

Does Keploy support JetStream?

Core publish, subscribe, and request-reply are captured, and JetStream publishes are recorded as the protocol exchanges they are. Stream and consumer management is not asserted on — check the repository for current coverage.

Does Keploy work with nats.go and nats-py?

Yes, and identically. Capture happens at the NATS protocol beneath the client, so nats.go, nats-py, nats.js, jnats, and async-nats all record and replay the same exchanges.

Is Keploy free to use with NATS?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any service with no seat limits. Nothing is installed into the server and no configuration change is required.

Keploy as a NATS testing framework

Keploy tests NATS publishers and subscribers by recording the NATS protocol beneath your client, capturing published subjects, delivered messages, and request-reply exchanges, then replaying them during tests. No nats-server runs and no JetStream stream is created.

Generate NATS tests free

keploy record -c "./orders-service"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a NATS team

Captured at the NATS protocol

Keploy records the text protocol beneath your client, so publishes replay with their real subject and payload, subscriptions with their delivered messages, and request-reply with the responder's actual reply.

Below nats.go, nats.py, nats.js, and jnats
Subjects and payloads preserved
Request-reply exchanges captured
Queue group deliveries recorded

Try Keploy for free Explore the docs

The problem

Why NATS integration tests slow teams down

The friction is rarely the assertions. It is everything around them — spinning up dependencies, keeping mocks honest, and repairing tests after every refactor.

Book a call Explore the docs

Three ways to do it

Testing NATS: by hand, with an embedded nats-server, or with Keploy

An embedded server gives real subject semantics and leaves every subscriber test waiting on asynchronous delivery. Keploy records the exchanges once and replays them deterministically.

By hand

an embedded nats-server

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for NATS vs what Keploy records

All three produce the same assertion. Only the third still passes after the next refactor without anyone editing it.

By hand2–4 hours

fake_bus.go

hand-written

// Hand-written fake: subject matching never happens.

package bus

type FakeBus struct {

Published []Message

}

func (f *FakeBus) Publish(subject string, data []byte) error {

// No wildcard matching, no subscriber, no reply.

f.Published = append(f.Published, Message{subject, data})

return nil

}

func (f *FakeBus) Request(subject string, data []byte) ([]byte, error) {

// The reply is typed out. No responder is involved.

return []byte(`{"status":"AUTHORIZED"}`), nil

}

The reply is a literal, so a missing responder or an unmatched subject passes here and silently times out in production.

an embedded nats-server1–2 hours

bus_embedded_test.go

tool-assisted

// An embedded nats-server: real subjects, async delivery.

package bus

import (

"testing"

"time"

"github.com/nats-io/nats.go"

)

func TestPublishesConfirmedOrder(t *testing.T) {

srv := runEmbeddedServer(t)

defer srv.Shutdown()

nc, _ := nats.Connect(srv.ClientURL())

defer nc.Close()

sub, _ := nc.SubscribeSync("orders.confirmed")

New(nc).Confirm("ord_1")

// Wait for delivery, or give up. This is the flaky part.

msg, err := sub.NextMsg(2 * time.Second)

if err != nil {

t.Fatalf("no delivery: %v", err)

}

if string(msg.Data) == "" {

t.Fatal("empty payload")

}

Real subject matching and fast startup — and the assertion still hangs on a two-second wait that fails under CI load.

With Keploy~5 minutes

mocks.yaml

auto-generated

# Recorded with: keploy record -c './orders-service'

# The NATS exchange, captured at the wire protocol.

version: api.keploy.io/v1beta1

kind: NATS

name: mock-3

spec:

publish:

subject: orders.confirmed

headers:

Content-Type: "application/json"

payload_base64: "eyJpZCI6Im9yZF8xIiwic3RhdGUiOiJDT05GSVJNRUQifQ=="

request_reply:

subject: payments.authorize

reply_to: "_INBOX.9fK2mQ"

# The real responder's reply, not a typed-out literal.

reply_payload_base64: "eyJzdGF0dXMiOiJBVVRIT1JJWkVEIn0="

The reply came from the real responder and the inbox subject is recorded, so a subject mismatch surfaces as a diff with no waiting.

Times are estimates for authoring one endpoint’s coverage from scratch, not measurements.

Explore the docs Request a trial

Keploy vs the alternatives

NATS testing tools, compared

The options a team on message brokers actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

Testcontainers

Embedded Kafka

MockConsumer / MockProducer

LocalStack

Postman

SmartBear ReadyAPI

Best in classStrongPartialNot covered

Assessments reflect each tool’s documented behaviour, not benchmark measurements.

Request a trial Book a call

How it works

Record your NATS app once, replay it forever

Keploy sits below your NATS process at the network layer. It watches the calls your app already makes, then serves them back on replay so tests run with no dependencies attached.

Your NATS appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

Gonats.go and the JetStream API

Pythonnats-py

Node.jsnats.js

Javajnats

+2 more NATS clients

An example shape of a captured call. Your own endpoints and dependencies come from your real traffic, so nothing here has to be written by hand.

Try Keploy for free Request a trial

Mock coverage

NATS clients Keploy records, driver by driver

Keploy captures NATS at the wire protocol, so 4 of these 6 clients need no adapter, no test double, and no NATS instance in CI.

Explore the docs Book a call

Quick start

Your first NATS test suite in under five minutes

Every command below runs against your existing NATS service. Nothing in your source tree changes.

1
1Install the Keploy CLI
A single binary. It needs a Linux kernel with eBPF support, or Docker on macOS and Windows — and it adds nothing to your project's dependencies.
curl -sSL https://keploy.io/install.sh | bash
2
2Record your service
Pass the command you already use to start the app. Keploy runs it and watches every socket it opens.
keploy record -c "./orders-service"
3
3Exercise the paths you care about
Trigger the endpoint that publishes, then let your subscriber handle the message so both halves of the exchange are recorded.
curl -X POST localhost:8080/orders/ord_1/confirm -d '{"paymentToken":"tok_123"}'
4
4Replay in CI
Replay serves the recorded dependency responses, so the job needs no service containers and no Docker daemon.
keploy test -c "./orders-service" --delay 8