Production-grade · behavioural testing · no mocks

Your code works.
Until production
breaks it.

A practice harness for the patterns senior engineers ship every day — idempotency, rate limiting, distributed locks, retry-safe workflows. Write against real Postgres and Redis. The harness hits your code with concurrent requests, timeouts, and partial failures, then shows you exactly which invariants held.

Start practicing Browse patterns

now testing›_

patterns

1.2k

scenarios

languages

Fig. 01·Harness output · /api/payments

harness · runningnode:22 · postgres:16 · redis:7

› running 7 scenarios against your implementation…
PASSbasic_request_handling
12ms
PASSconcurrent_requests· 5 concurrent, exactly_once
145ms
PASSduplicate_submission_handling
89ms
PASSdatabase_connection_recovery
203ms
FAILpartial_failure_recovery
340ms
expected: transaction rolled back on downstream failure
actual:   partial write committed, no rollback
PASStimeout_handling
156ms
SKIPhidden_scenario_3
--
5 passed, 1 failed, 1 hidden · score 71/100

How the harness works

Real infrastructure.
Per submission.

Every run gets its own isolated docker network with real Postgres and Redis sidecars. No mocks. No shared state. The scenario harness runs adjacent to your code, drives it over HTTP, and asserts on behavioural properties — not string equality.

sandboxhardened docker container
networkisolated, fresh per run
sidecarspostgres 16 · redis 7
timeouts120s hard cap
observationhttp + process signals

Fig. 02·Execution topology


         ┌─────────────────────────────┐         ┌─────────────────────────────┐
         │                             │         │                             │
         │   YOUR IMPLEMENTATION       │◀────────│   SCENARIO HARNESS          │
         │                             │  :3000  │                             │
         │   POST /api/payments        │         │   ▸ concurrent_x5           │
         │   GET  /api/payments/:id    │         │   ▸ timeout_injection       │
         │                             │────────▶│   ▸ partial_failure         │
         │   (your code, your image)   │  asserts│   (platform-controlled)     │
         │                             │         │                             │
         └──────┬──────────────┬───────┘         └─────────────────────────────┘
                │              │
           :5432│              │:6379
                ▼              ▼
         ┌──────────────┐ ┌──────────────┐
         │              │ │              │
         │  POSTGRES    │ │   REDIS      │
         │  (per-run)   │ │   (per-run)  │
         │              │ │              │
         └──────────────┘ └──────────────┘
             isolated docker network · fresh every submission

Your code runs in an isolated container with its own postgres and redis. The harness hits it over HTTP and observes behaviour.

The loop

Three steps, and then the failures find you.

01step

Pick a pattern

Idempotent endpoints, rate limiters, circuit breakers, graceful shutdown. Each challenge is scoped to one behavioural property you can name in a code review.

02step

Write real code

Your implementation runs as an HTTP server in an isolated container, alongside real Postgres and Redis. No mocks. Your code, your choices.

app.post('/api/payments', async (req, res) => {
  const { idempotencyKey, amount } = req.body
  // your implementation
})

03step

Face the failures

A scenario harness hits the running server with concurrent duplicates, network partitions, timeouts mid-transaction. You see which invariants held — and which didn't.

scenarios:
  - name: concurrent_duplicate_requests
    concurrent: 5
    expect: exactly_one_charge

Where it differs

Not string comparison.
Behavioural testing.

Other platforms check if your output matches an expected string. We spin up real infrastructure and observe whether your code survives production failure modes.