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.

Try the dashboard Try the sandbox

No sign-up. In the dashboard choose “Look around as demo”; in the sandbox sign in with demo.

dispatch runs builds served Dashboard CI pipeline Test suite Report
One run, end to end. Three repositories, meeting at three points.

Projects

Live

v1.0.0

Test Run Dashboard

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.

No password: choose “Look around as demo” on the sign-in page.

React, Cloudflare Workers, D1, R2

Open dashboard How it works

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

Open sandbox How it works

Code only

v1.0.0

API Automation Patterns

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

Playwright, TypeScript, Allure

Open the repository How it works
The dashboard and both suites Play one run How it fits together, step by step.

How it fits together

One run of the dashboard, from the Run button to the report on screen. Press play, or pick a step.

User browser Machine API key Dashboard, repo 1 Test suite, repo 2 or 3 Front end React Backend Worker · the only writer File storage R2 · private Database D1 · run rows CI pipeline GitHub Actions Test suite API or UI · one per run Test report Allure · one file picks + Run POST /runs session status, polled POST /runs no browser, same rules workflow_dispatch run_id · scope · style · workers queued row out, result back POST /webhook HMAC signed runs the branch builds PUT scoped storage token report, read back

Scroll sideways to see the whole diagram.

  1. Ask for a run. A person picks a suite and presses Run, and the front end sends POST /runs with their session. A machine holding an API key sends the same call straight to the backend, and meets the same rules.
  2. Queue it and dispatch. The backend writes a queued row to its database and dispatches a workflow in the suite’s repository, with the run’s id, scope, style and workers.
  3. Run the suite. The CI pipeline runs the branch, and the test suite builds one report.
  4. Send it back. The suite uploads the report into the dashboard’s private storage with a scoped token, then posts a signed result to the backend, which records it.
  5. Read it. The front end polls the backend for status, and the report is read back through the backend, never from storage directly.
Blue marks a crossing that has to prove who it is. Only the backend writes run rows, and the storage is never public.
The whole system page

Inside a suite run, what makes tests independent, what parallelism buys.

Test by Design

© 2026 Surakiart Yasaka