Bookodi TestBot — Live Demo & End-to-End QA Bot
A bot that runs a fictional UK restaurant inside the live product — for investor demos, and as an end-to-end check with API coverage.
- Role
- Sole engineer — design, chapters, dashboard, print bridge, reports
- Team
- Solo, AI-assisted
- Timeline
- Oct 2026
- Organisation
- Bookodi (XEOO)
- Code
- Proprietary (employer)
- Reading time
- 6 min
Playwright drives up to four real Chrome windows — owner, guest phone, kitchen display and waiter phone — through 21 chapters, from sign-up to the end-of-day report. It prints real tickets through its own Print Bridge and measures how much of the 180-endpoint API each run exercises.
Overview
Investors want to see the whole product working, not slides — and a team shipping fast wants to know the whole product still works. Bookodi TestBot does both: it signs up a restaurant, sets up its team, menu and floor, then runs a day of service across several screens while captions explain each step, and finishes with a report of every API call it made.
The problem
- A convincing demo has to show many roles at once — owner, guests, kitchen and waiters — on a live system that changes every week.
- Printing kitchen tickets is a highlight of the product, but there was no printer.
- “Does everything still work?” needed an honest number, not a feeling.
Context & constraints
The bot runs against the live product, so it had to be safe on real accounts: never touching payments, never importing a menu (which calls a paid AI model), never changing passwords and never running set-up on an account added by hand.
Approach
- Storyline — 21 chapters over five phases, arranged into two stories: a full day of service and an eight-minute investor cut that fast-forwards the set-up.
- Stage — one browser context per role, two of them emulating phones, tiled on screen and reopened if a presenter closes one mid-run. The actor clicks and types at human pace with a visible cursor and on-screen captions.
- On screen first — every step is tried through the interface; if the interface fails, the bot screenshots it, logs a warning and completes the step through the API, so the demo never stalls.
- Printing — the bot runs its own Print Bridge, speaking the same agent protocol as the desktop app, and renders each ESC/POS ticket as a paper slip with QR codes — or forwards it to a real printer.
- Measurement — every API call from every window is recorded against a catalogue generated from the backend’s router: coverage by area, slowest calls, server errors and calls missing from the catalogue.
- Operator dashboard — start, pause, resume and stop; a live view, an activity log and a strip of printed tickets. Pausing hands Chrome to the presenter.
Key capabilities
- 21 chapters: sign-up, set-up, bookings, POS, kitchen, online orders, waiter app, bills, guest care, CRM, analytics and AI
- Up to four synchronised windows: owner, guest phone, kitchen display and waiter phone
- Two stories: a full day, and an eight-minute investor cut
- Real ticket printing through its own Print Bridge, with on-screen paper slips
- Per-run API coverage report against a 180-endpoint catalogue
- Pause and hand over to the presenter, then resume from the same step
- Chapters safe to re-run: existing data is detected, bookings use live availability
- Optional AI-written restaurant content, with built-in fallbacks
Architecture
Operator
Orchestration
Live product
Observation
An operator dashboard drives a chapter runner, which choreographs several browser windows against the live product while a coverage recorder and a print bridge watch what happens. Select a component to trace its connections.
Key decisions
ADR-01On screen first, API as a fallback
- Context
- The bot drives a live product whose interface changes every week, in front of an audience.
- Decision
- Try every step through the interface; if it fails, screenshot it, log a warning and finish the step through the API.
- Trade-offs
- A demo never stalls, but a fallback could hide a regression — so every fallback is logged with a screenshot and counted in the report.
ADR-02Printers that exist only while the bot runs
- Context
- Ticket printing is a highlight of the demo, but there was no hardware — and a printer pointing nowhere would leave orders hanging.
- Decision
- Run the bot’s own Print Bridge with two virtual printers on documentation-only addresses, switched on only while the bridge is connected.
- Trade-offs
- It depends on an internal agent protocol — the same one the desktop app speaks — but tickets really print, and fail fast when the bot is not running.
ADR-03Coverage against the backend’s own router
- Context
- The team wanted an honest “how much of the API did we exercise” figure.
- Decision
- Generate the endpoint catalogue from the backend’s router, classify each endpoint by area and plan, and exclude by design what a restaurant can never reach.
- Trade-offs
- The catalogue must be re-synced as the backend grows — calls missing from it are reported, so drift is visible.
ADR-04Guardrails for real accounts
- Context
- The same bot can be pointed at a real customer’s restaurant.
- Decision
- Accounts added by hand are never set up automatically; payments, menu import and password changes are never touched; the model only writes words, never the facts the product validates.
- Trade-offs
- Less automation on real accounts, in exchange for zero risk to them.
Challenges
Two processes, one accounts file
Problem. The dashboard and the CLI could overwrite each other’s saved accounts.
Solution. The file became the single source of truth: read, modify and write atomically on every call — with a test proving two stores never clobber each other.
Coverage that undercounted
Problem. Empty 204 responses never fired the browser event the recorder listened to.
Solution. Count on the response event instead, and record time to first byte for every call.
A live environment that misbehaves
Problem. Sign-in occasionally stalled, toasts blocked clicks, presenters closed windows mid-run and optional AI calls returned server errors.
Solution. Each case is recovered and logged: stalled sign-ins retried, overlays dismissed, windows reopened still signed in, and product errors reported as findings instead of failing the chapter.
Restaurants that fill up
Problem. A restaurant used for many runs filled its diary, and some list calls slowed from 0.9 s to 5.2 s.
Solution. Bookings are chosen from live availability, chapters detect data that already exists — and the slowdown itself went into the findings.
Quality & delivery
Testing
- 21 unit tests (node:test) plus strict type-checking.
- Live verification: a run of the full-day story completed all 19 of its chapters with no fallbacks and no server errors, exercising 147+ of 158 reachable endpoints, printing 9 tickets and logging 38 realtime events. The investor cut runs in about 8 minutes.
- Every run produces an HTML and JSON report with coverage by area, the slowest responses and any server errors.
Deployment
Runs on a laptop today, with the dashboard on loopback; the next phase moves it to a server behind a password, running headless.
Outcome
- Chapters
- 21
- Sign-up to end-of-day report
- Reachable API endpoints in one run
- 147+ / 158
- Full-day story, no fallbacks
- Investor cut
- ≈8 min
- Measured: 7.9 min
- Defects in the QA report
- 96
- Across the web app, desktop and mobile work
Phases one to five shipped in two days. The bot became the team’s demo tool and its end-to-end check — and, with the layout audit from the mobile project, the basis of a QA report covering 30 September to 14 October: 96 defects (35 high, 41 medium, 20 low), each with its cause and a ready-to-use fix, handed to the web team.
Lessons
- A demo and a test are the same program if you measure what the demo touches.
- Fallbacks keep a show running — but only honest logging keeps them from hiding bugs.
- Safety rules belong in code when a tool can be pointed at real customers.
Building something similar?
Tell me what you’re working on — I reply to every serious message.
Related work
Bookodi Mobile — Android & iOS Apps
A Capacitor 8 shell that runs the live Bookodi dashboard inside native Android and iOS apps, with a page layer injected before the web app loads and a mobile layout layer. A layout audit across 123 page states found 915 problems on the website and none in the app.
- TypeScript
- Java
- Swift
- HTML & CSS
- Vite
- Capacitor
- +4
Bookodi Desktop & Print Bridge
Native desktop app for the Bookodi restaurant platform with a built-in Print Bridge: it pairs with the cloud in one click, discovers printers on the local network and delivers server-rendered tickets over raw TCP, IPP, LPD, CUPS or the Windows spooler.
- TypeScript
- Vite
- Electron
- Node.js
- WebSockets
- GitHub Actions
- +3