E2E testing for beginners: the first test you can actually watch.

For a beginner building a small web app, starting with one good E2E test is often more motivating than writing ten unit tests. E2E asks a single concrete question: when a real user clicks through my app, does the thing they care about still work. Unit tests are worth it later, but they require you to have an opinion about the internal shape of the code, which a beginner often does not yet have. With Assrt you can write your first E2E test in plain English as a Markdown #Case, hit run, and watch the browser do it. That loop teaches you more about your own app in 10 minutes than reading a testing-pyramid article.

Integration tests call your code across module boundaries and assert on the return value. E2E tests drive the actual UI your users see: they click buttons, type in inputs, wait for real network responses, and assert on what is on the screen. If your app is a web form that submits to an API, an integration test might call the API handler directly with a fake request body; an E2E test opens the page, types into the form, presses Submit, and verifies the success message appears. For beginners, E2E is usually the easier one to start with because the test reads like a description of what you would do manually.

Not with Assrt. The test format is Markdown: a header line like #Case 1: Sign up with email followed by 3-5 imperative English lines. Example: Navigate to /signup. Use a disposable email. Enter the OTP. Verify the dashboard heading appears. A coding agent interprets that, picks browser actions at runtime, and runs them through real Playwright. You never import a test framework. You never wire up a page-object pattern. If you can write a commit message or a Jira ticket, you can write an Assrt #Case. Traditional tools (Cypress, Selenium, Playwright directly) do require JavaScript or Python, and that is still a fine path, just not the only one.

Headless means the browser does not open a window: it runs in the background with no visible UI. For production CI that is great, because it is faster. For a beginner running a test for the first time it is disorienting, because you get a terminal that sits there for 30 seconds and then prints PASS or FAIL with no sense of what actually happened. Assrt records a real video of every run and, if the test fails, it also shows the injected red cursor moving between elements, ripple animations on each click, and keystroke toasts for every typed character. A beginner can watch the replay and immediately tell whether the agent clicked the wrong button, typed the wrong text, or waited too short.

Four elements, all at z-index 2147483647 (the max 32-bit int) so they always float above your app's own DOM. First, a 20px red cursor (rgba(239,68,68,0.85), white border, soft red glow) that glides between click targets over 0.3 seconds using a CSS transition. Second, a 40px ripple ring that scales from 0.5x to 2x on each click and fades to zero opacity in 50ms. Third, a monospace green-on-black keystroke toast that displays the last key pressed and fades after 2500ms. Fourth, a 6px green heartbeat in the bottom-right that animates opacity between 0.2 and 0.8 every 800ms, whose only job is to force continuous compositor frames so the CDP screencast video never stalls. The script that creates them lives at assrt-mcp/src/core/browser.ts lines 33-98 and is re-injected on every navigate() call.

Because browsers optimize away frame rendering when the page is idle. If the test is waiting for a slow network response and nothing on the page is moving, the CDP (Chrome DevTools Protocol) screencast that captures the video will start dropping frames. When you replay, it looks like the test froze, which is confusing for a beginner who is already nervous about whether anything is working. The heartbeat is a 6-pixel dot in the bottom-right that animates every 800ms forever. It is small enough that it does not distract, and its continuous animation forces the compositor to keep producing frames, so your video stays smooth even during long waits.

No, and you can verify this by reading the inject script. Every overlay element has pointer-events: none so it cannot intercept clicks or hover events. Every overlay is position: fixed with z-index 2147483647, which takes it out of your normal layout flow. The injection is guarded with if (!window.__pias_cursor_injected) so it only runs once per page. When the page navigates, the new DOM wipes the overlay and navigate() re-injects it. Nothing the overlay does can affect your app's click handlers, form state, animations, or layout. The only thing it changes is what the video looks like when you replay it.

Point Assrt at your app's landing page and ask it to verify the main heading. That is it. A one-line #Case like 'Navigate to /. Verify the main heading contains Your App Name' runs in under 2 seconds and confirms your test pipeline works end to end: browser launch, navigation, snapshot, assertion, video recording, pass/fail exit code. Once that passes, add a second case for whatever matters most in your app, usually signup or sign-in. If signup involves an email verification code, the built-in create_temp_email and wait_for_verification_code tools handle the inbox round-trip without you wiring Mailosaur.

Three things land on disk: a WebM video of the full run, a text transcript of every tool call the agent made (click what, type what, assert what), and a screenshot at the failure point. Open the video first. The injected cursor shows you exactly where the agent tried to click; the ripples show you exactly when a click fired; the toasts show you each keystroke. If the cursor landed on the wrong element, your plan line was ambiguous and you can rephrase it. If the cursor landed on the right element but the click did not do anything, the page was still loading and you add wait_for_stable. You are not guessing at stack traces. You are watching a video of a bot using your app.

It is the same code path either way. The overlay injection is purely cosmetic and runs in local and CI mode the same. In CI you would typically set --no-auto-open so the video player does not try to launch a browser on the CI runner, but the video itself still gets written to /tmp/assrt/videos and can be uploaded as a build artifact. Teams that adopted it as a beginner onboarding tool have kept it for regression runs because engineers who inherit a failing test still benefit from a replay with a visible cursor. The visibility of the runner is a feature, not training wheels.