Vojtěch Barta
Menu
Professional Hobbies Blog Contact

Tester exploring vibe coding

In autumn I wrapped up an interview on the PodVocasem podcast by saying that, so far, AI had mostly passed me by — and that it might come back to bite me later.

I decided to lean into that a little — mainly through the lens of testing — and see what I could actually get out of it.

First I wanted to get back to the basics. I remembered my wife (a teacher) had recently needed a crossword for her pupils at school, and getting a usable image straight out of various LLMs was a non-starter. So I built a small app for that. A second app generates exercises for past-tense verb forms. Both run on Učitelé – nástroje pro výuku (small tools for teachers). I tried several tools, settled on Cursor, brushed up my Git workflow, and added basic unit and UI tests.

The next step was a demo e‑shop (React + Vite, Node/Express, Prisma, MySQL), built with vibe coding in Cursor. It is still not a production shop — a training playground for testing, automation, and learning — but it now has a documented Azure deployment path, GitHub Actions, and more; see April 2026 — progress below. The code is on GitHub: github.com/vojtechbarta/testing.

What makes it the most interesting “target” for me is controlled fault injection:

  • Faults live in the database as configuration (name, description, level: UI / API / Unit, on/off, optional failure rate).
  • The tester turns them on or off in the UI and can tune them.
  • The same scenario can fail in the frontend (e.g. double submission), in the API (distorted quantity in the payload), or lowest in the logic (e.g. double increment on persist).
  • You switch the level and immediately see the same steps leading somewhere else — depending on where the system “stops working”.

How to practise testing on it

  • Bottom of the pyramid: unit tests for services (e.g. Vitest) against mocks — fast feedback.
  • Middle: API and integration — headers (e.g. cart session), error responses, edge cases with faults enabled.
  • Top: Playwright — page objects, checking prices and cart, reports, trace and screenshots on failure, and so on.
  • AI can scaffold each of those layers reasonably well; it does not always push hard enough — that is where the tester steps in and adds more tests.
  • Broader use of AI in testing: from code, fault tables, and user stories you can generate ideas for test cases, risks, checklists, and scenarios.

What next?

  • More faults and misbehaviour across whole user journeys — that is what I enjoy most: design a fault, then figure out how to find it and which layer catches it first, without noise bubbling up unnecessarily.
  • Keep pushing on test-pyramid visibility and coverage — using structured reports and judgment, not treating a single percentage as the goal.
  • Templates for bug reports.
  • Better generation and maintenance of automated tests.
  • Tools for exploratory testing.

April 2026 — progress

Since writing the notes above, the playground has grown in the directions I was hoping for. The repo is still the same github.com/vojtechbarta/testing; the README now documents a full path from a two-terminal local setup to something you can run in the cloud.

Deploying and operating it. The app is split the usual way: the Vite frontend on Azure Static Web Apps, the Node API on Azure Container Apps (or optionally App Service), with Azure Database for MySQL and a container registry. Infrastructure is expressed in Bicep and wired together with azure/deploy.sh; there is also a small runbook for when something goes wrong during deploy or seeding.

You can open the deployed shop at jolly-flower-0362d8e1e.1.azurestaticapps.net and the live API docs (Swagger) at the Container Apps host (/docs).

CI. GitHub Actions deploy the frontend when frontend/ changes and the API when backend/ or azure/ changes. Database migrations run at container startup; seeding is intentionally manual — there is a separate workflow you trigger when you want to reset or populate data in the cloud database.

Easier local and API work. Optional Docker Compose runs MySQL 8.4 so you do not need a local server install. The backend exposes OpenAPI/Swagger (/docs) and a simple health endpoint for smoke checks after deploy.

More to test against. Checkout now goes through a mock payment gateway, with JSON-driven payment outcomes (including per–e-mail behaviour) alongside the existing fault injection machinery. That gives more realistic end-to-end stories without turning the project into a “real” payments integration.

Coverage and agents. I added Cursor-side test-pyramid skills: one pass generates a structured coverage-style report across unit, internal API, and UI layers; another proposes small batches of new tests with an explicit approval step. Outputs live under agents-results/ in the repo — useful for iterating, not as a single “coverage number” to worship.

Faults vs. baselines. The rule of the road is unchanged: baseline tests stay strict for the non-faulty system; when faults are on, you add or rely on dedicated fault-mode checks instead of weakening green builds.