Test by Design

Testing tools, and the reasoning behind them.

Test systems I designed end to end, with the reasoning behind each choice written down. Two of them are running now — open them.

Dashboard and test suites

A dashboard that runs two test suites and serves their reports.

How it fits together Diagrams of one run, end to end

Live

Test Run Dashboard v1.0.0

Self-service test runs. The hard part is not the Run button — it is who may run what, and who may then see the result.

React, Cloudflare Workers, D1, R2

Code only

API Automation Patterns v1.0.0

The same API suite built twice against one contract — 111 tests each — so two structures can be compared on evidence.

Playwright, TypeScript, Allure

Code only

UI Automation Patterns

The same browser journeys built two ways, against an application where five of six accounts are broken on purpose.

Playwright, TypeScript, Allure

Payment sandbox

Stands in for a payment provider, so a test decides what comes back.

How it works Diagram of the sandbox’s two doors

Live

Paygate Sandbox

Settle, decline with a specific code, time out, or send the same webhook twice out of order — on demand. Sign in with demo for sample payments of your own.

Node, Vercel, Vercel KV

Another shape for API suites

A design note, for when the order is the thing under test.

How it works Diagram of what one break costs

Design note

Scenario suites in Postman and Newman

Sequential and generated at run time — the right shape when order is what is being tested, and a costly one when it is not.

Postman, Newman

Test by Design