Skip to content

testing-tools.mdx

Latest commit

 

History

History
95 lines (66 loc) · 2.66 KB

testing-tools.mdx

File metadata and controls

95 lines (66 loc) · 2.66 KB
Raw
title Testing Tools
description Chaos injection, cloud-parity strict mode, request logging, and record & replay.

These tools help you test how your app behaves against a realistic — and sometimes hostile — Upstash, all locally and without burning cloud quota.

Chaos injection

Simulate a slow or flaky upstream so you can verify timeouts, retries, and fallback logic.

Flag Env Effect
--inject-latency <ms> UPSTASH_INJECT_LATENCY_MS Adds fixed latency to every request
--inject-error-rate <0.0–1.0> UPSTASH_INJECT_ERROR_RATE Fails requests with the given probability 
# Every request is 200ms slower and 10% of requests fail with a 500
upstash-redis-local --inject-latency 200 --inject-error-rate 0.1

A failed request returns HTTP 500:

{ "error": "ERR simulated upstream failure (chaos injection)" }
Pair this with the [rate-limit simulator](/guides/rate-limits) to reproduce production conditions like "Upstash is slow and we're near our quota".

Cloud-parity strict mode

Upstash REST rejects commands that don't fit a request/response model (blocking pops, SUBSCRIBE, MULTI/EXEC, MONITOR, replication, etc.). By default this proxy allows them — convenient, but it means code can work locally and break in production.

Enable strict mode to reject exactly what Upstash REST rejects:

upstash-redis-local --strict-upstash
curl http://localhost:8000/SUBSCRIBE/news -H "Authorization: Bearer local-dev-token"
# { "error": "ERR command 'SUBSCRIBE' is not supported by Upstash REST (strict mode)" }
Turn this on in CI so unsupported commands fail your tests before they reach production.

Request logging

Print every request — method, path, status, and duration — to stdout:

upstash-redis-local --log-requests
INFO  request  {"method":"GET","path":"/GET/user:1","status":200,"took":"0.41ms"}

Record & replay

Capture every command your app issues, then replay the whole session later to reproduce bugs or seed a fresh instance.

Record

upstash-redis-local --record session.jsonl

Each executed command is appended as one JSON line:

["SET","user:1","alice"]
["GET","user:1"]
["INCR","counter"]

Replay

Use the CLI to replay against any running server:

upstash-local replay --input session.jsonl --url http://localhost:8000 --token local-dev-token
✅ Replayed 3 commands (3 ok, 0 failed) from session.jsonl
Replay is great for deterministic CI fixtures: record once against a real session, commit the `.jsonl`, and replay it to set up test data.