How do I mock DynamoDB in tests?

Record your application once against a real DynamoDB table with Keploy. It captures the SDK's HTTP exchange — items, capacity, and pagination tokens — then answers the same calls from that recording with no table and no credentials.

Does Keploy preserve DynamoDB attribute value types?

Yes. Items replay in their attribute-value encoding, so an N arrives as the string DynamoDB really sends and nested M and L structures stay intact. The SDK's marshalling runs on every replay rather than being bypassed.

Do I need AWS credentials to replay DynamoDB tests?

No. Replay answers from the recording without signing a request or reaching AWS, so a CI job needs no IAM role or access key — and a test cannot accidentally write to a real table.

Does Keploy work with boto3 and the AWS SDK for Go?

Yes, and identically. Capture happens at the HTTP layer beneath the SDK, so boto3, aws-sdk-go-v2, @aws-sdk/client-dynamodb, and the Java Enhanced Client all record and replay the same exchanges.

Is Keploy free to use with DynamoDB?

Yes. The Keploy CLI is open source under Apache 2.0 and free to run on any service with no seat limits. Nothing is deployed into AWS and no IAM change is required to record.

Keploy as a DynamoDB testing framework

Keploy mocks DynamoDB by recording the AWS SDK's HTTP traffic, capturing the items, capacity metadata, and pagination tokens the service returned, then replaying them in tests. No DynamoDB Local runs, no table is defined, and no AWS credentials are needed.

Generate DynamoDB tests free

keploy record -c "./orders-service"

18.4K+

1.2M+300M+mocks createdSlack

What Keploy gives a DynamoDB team

Captured at the DynamoDB HTTP API

The AWS SDK talks to DynamoDB over HTTPS with a JSON protocol, so Keploy records the real exchange — items in their attribute-value encoding, consumed capacity, and LastEvaluatedKey included.

Below every AWS SDK language binding
Attribute-value types preserved
ConsumedCapacity captured
Pagination tokens replayed

Try Keploy for free Explore the docs

The problem

Why DynamoDB 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 DynamoDB: by hand, with DynamoDB Local, or with Keploy

DynamoDB Local is a separate implementation that still needs tables created per environment. Keploy records the managed service once and replays exactly what it returned.

By hand

DynamoDB Local

With Keploy

Select any row for the full comparison, with code.

Get started Book a call

Same coverage, three costs

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

order_store_stub.go

hand-written

// Hand-written stub: marshalling is never exercised.

package store

type StubOrderStore struct{}

func (StubOrderStore) Get(id string) (Order, error) {

// The SDK would return N as a string and marshal it. This does not.

return Order{ID: id, AmountMinor: 4200, State: "NEW"}, nil

}

func (StubOrderStore) Put(o Order) error {

// No key schema, no condition expression, no capacity accounting.

return nil

}

Attribute-value marshalling, condition expressions, and key schema validation are all absent, so a type coercion bug reaches production unseen.

DynamoDB Local1–2 hours

order_store_test.go

tool-assisted

// DynamoDB Local: a separate implementation of the API.

package store

import (

"context"

"testing"

"github.com/aws/aws-sdk-go-v2/service/dynamodb"

)

func TestReadsAnItem(t *testing.T) {

client := localClient(t) // points at localhost:8000

// Every environment recreates the table and its indexes.

mustCreateTable(t, client, ordersTableSpec)

mustPutItem(t, client, ordersItem("ord_1", 4200, "NEW"))

order, err := New(client).Get(context.Background(), "ord_1")

if err != nil || order.AmountMinor != 4200 {

t.Fatalf("got %+v err %v", order, err)

}

Real SDK marshalling against a local endpoint — and it needs a running process plus table and index creation before every run.

With Keploy~5 minutes

mocks.yaml

auto-generated

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

# The DynamoDB response, captured at the HTTP API layer.

version: api.keploy.io/v1beta1

kind: Http

name: mock-2

spec:

request:

method: POST

url: https://dynamodb.example.com/

header:

X-Amz-Target: DynamoDB_20120810.GetItem

body: '{"TableName":"orders","Key":{"id":{"S":"ord_1"}}}'

response:

status_code: 200

body:

Item:

id: { S: "ord_1" }

# DynamoDB returns numbers as strings. The SDK marshals them.

amount_minor: { N: "4200" }

state: { S: "NEW" }

ConsumedCapacity:

TableName: "orders"

CapacityUnits: 0.5

The N value replays as the string DynamoDB really sends, so the SDK's marshalling runs on every replay instead of being bypassed.

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

Explore the docs Request a trial

Keploy vs the alternatives

DynamoDB testing tools, compared

The options a team on document and wide-column stores actually reaches for, and where each one genuinely wins. Select a row for the full comparison.

Keploy

Testcontainers

mongodb-memory-server

mongomock

Fongo

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

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

RecordingKeploy proxyeBPF · userspace

Goaws-sdk-go-v2 dynamodb and attributevalue

Pythonboto3 and aioboto3

Node.js@aws-sdk/client-dynamodb and DocumentClient

Javathe AWS SDK v2 DynamoDbClient and Enhanced Client

+2 more DynamoDB 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

DynamoDB clients Keploy records, driver by driver

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

Explore the docs Book a call

Quick start

Your first DynamoDB test suite in under five minutes

Every command below runs against your existing DynamoDB 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
Run the app against your development table. Every GetItem, Query, and PutItem, with the response the service returned, is captured together.
curl localhost:8080/orders/ord_1
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