Test environment

Skip to content
← Self-paced learning

Self-paced learning

Teach AI to check its work

Give an AI agent tests, limits and a repeatable workflow.

Your lessons

  1. Move the tracker onto Vite and record a baseline

    Scaffold a Vite + TypeScript project from your Module 1 HTML/CSS/JS tracker, write observable acceptance criteria, and record what actually happens before any agent change.

  2. Write unit and integration tests that can fail

    Split pure rules from DOM and storage, write Vitest checks that fail when the behaviour breaks, and prove a failure path instead of only the happy path.

  3. Prove the real browser, including failure and keyboard use

    Drive Chromium against your local Vite server: main flow with reload, a blocked-storage failure, an axe scan, and a keyboard-only add — without pointing tests at random websites.

  4. Run one bounded plan–code–test–fix loop

    Give OpenCode one criterion, hard file and command bounds, stopping rules including no test weakening, and a run log with a real stop reason.

  5. Watch permissions fire; do not confuse cost reports with caps

    Configure allow/ask/deny so denied actions are refused, test edits ask, secrets stay out of the repo, and you can tell a hard limit from a cost report you read after the run.

  6. Make CI run the checks — and do not deploy from this module

    Add a GitHub Actions verify job that installs from the lockfile, runs types, tests, Playwright, and build, blocks on red, and leaves deploy commented out with a written rollback plan.

Your project

Give an AI agent tests, limits and a repeatable workflow.

Submit the Vite + TypeScript task tracker you bounded in this module: public URL or repository URL, what you changed and why, and the checks you actually ran. Do not paste API keys, .env contents, or auth.json. Evidence is stored as you wrote it and is self-reported pending review — it is not automatically certified, graded by an automated reviewer, or a certificate.

Check your work
  • Vite + TypeScript tracker with Module 1 behaviour

    The app runs via npm run dev on a pinned local URL, uses TypeScript sources (not the Module 1 public/ files as the live source), and storage is described as per-browser localStorage — including that the Module 1 key does not automatically migrate.

  • Observable criteria and a recorded baseline

    acceptance-criteria.md (or equivalent) has setup/action/result rows, each mapped to a named check or explicitly not covered, with a baseline filled before later changes.

  • Unit, integration, and browser tests including failure and keyboard/axe

    npm test and npm run test:e2e show non-zero passing counts; at least one failure-path check exists; axe is reported as an automated floor plus a keyboard-only flow, not as a WCAG certificate.

  • One bounded agent run with a stop reason and reviewed diff

    A brief bounds files, commands, steps, and time; the log has real command output; the stop reason is listed; test weakening was refused or reverted (or the learner states what they would have done).

  • Observed permission gates and honest limits

    debug config plus three probes (including a deny and an ask on tests); agent.build.steps is set; opencode stats is recorded as an after-the-fact report; --auto and a live deploy are not used as the control story.

  • CI verify without an active deploy job

    A verify workflow runs npm ci, types, tests, Playwright with --with-deps, and build; a red run is shown; rollback names a real sha; no claim that CI green deployed the app or that an OpenCode GitHub bot reviewed it.

Complete all six lessons to submit your project.