How do I mock Redis in tests without running a server?

Record your application once against a real Redis with Keploy. It captures every command and reply at the RESP protocol level, then answers the same commands from that recording during tests — with no Redis process and no in-process fake.

Is Keploy a fakeredis or miniredis alternative?

For replay, yes. Both reimplement a documented subset of Redis in-process, so uncommon commands can diverge. Keploy replays replies that came from Redis itself. Keep the fakes when you want to assert directly on stored keys.

Can Keploy test cache-miss and write-back logic?

Yes, and this is where it helps most. Recording a cold key captures the real miss reply, the write-back with its actual TTL argument, and the subsequent hit — so the fallthrough branch most suites skip is covered by default.

Does Keploy handle Redis pipelines and MULTI/EXEC?

Yes. RESP carries pipelines and transactions as ordered command and reply sequences, so Keploy records them as a multi-reply exchange and replays them in the same order with the same responses the server sent.

Does Keploy work with Lettuce, ioredis, and redis-py?

Yes, and identically. Capture happens at the RESP protocol beneath the client, so Lettuce, Jedis, ioredis, node-redis, redis-py, and go-redis all record and replay the same exchanges regardless of client API.

Can Keploy mock Redis TTL and expiry behaviour?

Yes. The TTL replies the server returned are recorded alongside each command, so an EXPIRE in milliseconds where seconds were meant shows up as a wrong recorded value rather than being silently discarded by a stub.

Keploy as a Redis testing framework

Keploy mocks Redis by recording the RESP protocol beneath your client, capturing every GET, SET, TTL, and pipeline response exactly as the server replied, then replaying them during tests. No Redis runs in CI and no in-process fake is substituted for the real server.

Generate Redis tests free

keploy record -c "./orders-service"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a Redis team

Captured at RESP over TCP

Keploy reads the RESP protocol beneath your client, recording each command and reply in order — so pipelines and MULTI/EXEC blocks replay as the multi-reply exchanges they really were.

Below Lettuce, ioredis, redis-py, go-redis
Commands and replies kept in order
Pipelines and transactions preserved
Real nil replies, not a stub default

Try Keploy for free Explore the docs

The problem

Why Redis 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 Redis: by hand, with miniredis / fakeredis, or with Keploy

miniredis and fakeredis implement a documented subset of Redis in-process, so anything past common string and hash commands can diverge. Keploy replays what your real server sent.

By hand

miniredis / fakeredis

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

What you write for Redis 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

cache_stub.go

hand-written

// Hand-written stub: no TTL, no eviction, no miss behaviour.

package cache

import "time"

type StubCache struct {

values map[string]string

}

func NewStubCache() *StubCache {

return &StubCache{values: map[string]string{

"order:ord_1": `{"id":"ord_1","state":"NEW"}`,

}}

}

func (s *StubCache) Get(key string) (string, error) {

// Always a hit. The fallthrough path is never exercised.

return s.values[key], nil

}

func (s *StubCache) SetEX(key, val string, ttl time.Duration) error {

// The TTL argument is accepted and discarded.

s.values[key] = val

return nil

}

The TTL is accepted and thrown away, so passing milliseconds where seconds were meant is impossible to catch. Every read is a hit.

miniredis / fakeredis1–2 hours

cache_miniredis_test.go

tool-assisted

// miniredis: an in-process Redis reimplementation.

package cache

import (

"testing"

"time"

"github.com/alicebob/miniredis/v2"

"github.com/redis/go-redis/v9"

)

func TestOrderCache(t *testing.T) {

srv := miniredis.RunT(t)

rdb := redis.NewClient(&redis.Options{Addr: srv.Addr()})

c := New(rdb)

_ = c.SetEX("order:ord_1", `{"state":"NEW"}`, 60*time.Second)

got, err := c.Get("order:ord_1")

if err != nil || got == "" {

t.Fatalf("expected a hit, got %q err %v", got, err)

}

// Time must be advanced manually; it is not real expiry.

srv.FastForward(61 * time.Second)

if _, err := c.Get("order:ord_1"); err != redis.Nil {

t.Fatal("expected the key to have expired")

}

A real improvement on the stub, and still a reimplementation: expiry is simulated with FastForward, and anything outside the implemented command set may diverge.

With Keploy~5 minutes

mocks.yaml

auto-generated

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

# Two real exchanges: a miss, then the write-back.

version: api.keploy.io/v1beta1

kind: Redis

name: mock-7

spec:

exchanges:

- request: ["GET", "order:ord_1"]

# The real miss reply — this is the branch stubs skip.

response: null

- request: ["SETEX", "order:ord_1", "60", "{\"state\":\"NEW\"}"]

response: "OK"

- request: ["TTL", "order:ord_1"]

response: 60

- request: ["GET", "order:ord_1"]

response: "{\"state\":\"NEW\"}"

The recorded sequence includes the miss, the write-back with its real TTL argument, and the subsequent hit — the whole cache path, captured as it happened.

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

Explore the docs Request a trial

Keploy vs the alternatives

Redis testing tools, compared

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

Keploy

Testcontainers

fakeredis

miniredis

redis-mock

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 Redis app once, replay it forever

Keploy sits below your Redis 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 Redis appGET/api/v1/orders/{id}200

RecordingKeploy proxyeBPF · userspace

JavaLettuce, Jedis, and Spring Data Redis

Node.jsioredis and node-redis

Pythonredis-py and django-redis

Gogo-redis and redigo

+4 more Redis 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

Redis clients Keploy records, driver by driver

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

Auto-mocked
JavaView page
Lettuce, Jedis, and Spring Data Redis
Auto-mocked
Node.jsView page
ioredis and node-redis
Auto-mocked
PythonView page
redis-py and django-redis
Auto-mocked
GoView page
go-redis and redigo
Auto-mocked
Spring BootView page
Spring Cache over Redis
Auto-mocked
DjangoView page
The cache framework's Redis backend
Partial
Redis Cluster
Cluster slot redirection over RESP
Partial
Redis Streams
XADD and XREADGROUP exchanges

Explore the docs Book a call

Quick start

Your first Redis test suite in under five minutes

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

1
1Install the Keploy CLI
One binary on the recording machine. Nothing is installed into Redis and no client wrapper is needed.
curl -sSL https://keploy.io/install.sh | bash
2
2Record with your development Redis reachable
Run the app as usual. Every command and reply is captured in order, misses included.
keploy record -c "./orders-service"
3
3Exercise both cache branches
Hit an endpoint on a cold key to record the miss and write-back, then hit it again to record the hit.
redis-cli DEL order:ord_1
curl localhost:8080/orders/ord_1 # records the miss
curl localhost:8080/orders/ord_1 # records the hit
4
4Replay with Redis stopped
Shut Redis down and run the suite. If replay passes, every command your code issues is answered by a recorded mock.
keploy test -c "./orders-service" --delay 8