Introduction

Takazudo's personal frontend testing strategy guide for AI-assisted development

Personal dev notes by Takazudo. Not official testing documentation. Written for personal reference and AI-assisted coding.

This site covers frontend testing strategy for AI-assisted development. The focus is on choosing the right testing approach when working with AI coding agents -- knowing when a unit test is sufficient, when you need browser-level verification, and how to avoid the common trap of false confidence from passing tests that do not actually verify what matters.

What This Covers

These are the core topics documented here, all based on patterns extracted from real production projects:

• Testing Levels -- The 6-level escalation ladder from unit tests to AI-based visual verification, each with increasing coverage and decreasing blind spots

• Decision Guide -- Which testing level to use based on what changed, where and when a test should run (execution tiers), common failure patterns when the wrong level is chosen, required behaviors for AI agents, and an archetype playbook for picking a starting test suite by repo type

• Tool Patterns -- Pages organized around a specific tool or implementation technique, not a project shape: Vitest, Playwright, visual regression, browser-in-container verification, and cargo-nextest

• Project Recipes -- Pages organized around a repo or project shape, not a single tool: backend, Tauri, remark/rehype plugins, and built-site integrity

• CI Operations -- Running suites across CI, deploys, and releases: environment-tiered testing, smoke tests, scheduled re-exam, branch strategy, publishing, and runner sizing

• Test Integrity -- Ways tests deceive -- flakes, false greens, self-agreement, fixture traps -- and the discipline that prevents them

• Tools Reference -- Quick lookup of tools and commands for each testing level

The Core Insight

The single most important concept in AI-assisted testing is test level escalation. When an AI agent fixes a bug and declares it resolved, the fix is only as reliable as the testing method used to verify it. A unit test can confirm logic is correct, but it cannot confirm that the user actually sees the result on screen. The gap between "logically correct" and "visually correct" is the most common source of false confidence.

Testing should escalate, not repeat. When a lower-level test passes but the problem persists, move to the next level:

1. Level 1 -- Unit/Logic Tests (vitest, jest)

2. Level 2 -- DOM-based Component Tests (jsdom, Testing Library)

3. Level 3 -- Build Output Verification (read built files)

4. Level 4 -- E2E Browser Tests (Playwright, headless browser)

5. Level 5 -- Deterministic + Visual Verification (verify-ui + headless browser)

6. Level 6 -- AI-Based Visual Verification

Level 6 is not the natural top rung of a ladder you climb by default -- it is a final-resort escape hatch for the rare case where neither Level 4 nor Level 5 can reach the assertion (canvas-driven editors, free-form drawing, multi-layer compositing). It is non-deterministic and never belongs in a CI gate.

A Second Axis: Level vs. Tier

The levels above answer what a test can see. A separate question is where and when it runs -- the execution tier (inner loop, PR CI, a nightly schedule, a local heavy lane). A pixel-level Level 5 spec can run on every PR, or only on a schedule if it needs a real GPU; a plain Level 1 unit test almost always lives in the inner loop and the PR gate. "Too heavy for PR CI" is a tier question, not a reason to drop to a lower level. See Execution Tiers for the full breakdown.

How to Use This Guide

1. Start with the Decision Guide to determine which testing level fits your current task

2. Read the Testing Levels section for detailed coverage of each level

3. Reference the pattern categories -- Tool Patterns, Project Recipes, CI Operations, and Test Integrity -- for production-tested configurations

4. Keep the Tools Reference open for quick lookup