Test your app before you share it

Your outcome

Run a small set of checks that can detect a real task-tracker defect, and record what remains untested before sharing the app. A green build alone does not establish that saving works.

Starting point

Use the shared task tracker download, Node.js 20+, and a browser with storage enabled. Read its brief and bug report first. The planning increment covers create/refresh; the supplied second increment adds edit/delete. Test an app guides test selection; App and workspace blueprint carries the shared verification record.

1. Choose the check by the failure it must detect

Use unit checks for a title-validation rule, integration checks for writes followed by fresh reads, browser checks for Add -> refresh through the actual interface, and manual checks for wording, keyboard access, and layout. These are useful categories, not the only four kinds of testing.

Map AC-1 through AC-4 to create, refresh, invalid input, and failed write. Add AC-5 for an edited title surviving refresh and AC-6 for a deleted task staying deleted. For an empty list, expect "No tasks yet" and an available input, not a blank page.

2. Prove the regression check can catch the defect

Run from the extracted examples/task-tracker directory:

node verify.cjs --mode broken
node verify.cjs --mode fixed

The first command must exit 1 at AC-2: reopening the store loses the new task. The second must exit 0 with AC-1 through AC-6 passing. uses the same assertions in both modes. It also injects a rejected storage write and verifies that no successful row appears.