Start extension-based testing ->
AI-Powered Testing Workflow with BYOB Extension
BYOB testing is not static linting. It is a coordinated browser workflow across modal orchestration, extension connectivity, runtime routing, and structured event parsing.
When it works, you get real behavior validation and useful reports. This guide explains exactly how to use it well.
TLDR
- Test modal initializes a session and issues extension handshake data.
- Extension connects to the test bridge.
- Browser-level actions execute against preview environment.
- Event stream returns
test_result,report, and activity logs. - You can provide required inputs mid-run and continue.
End-to-end sequence
Modal phases and meaning
- Connecting: session and extension handshake setup.
- Reading: context and test config preparation.
- Testing: active run in progress.
- Awaiting input: system needs secure user-provided value.
- Done: report and artifacts ready.
- Error: run stopped with specific failure reason.
Understanding these phases helps you debug faster.
Why extension is necessary for deep checks
Some validations require real browser state.
- route transitions
- click and input events
- render timing and visibility
- interactive element behavior
Without extension bridge, those checks either do not run or lose fidelity.
Test run from session start to report view
Mid-run input requests
Certain flows cannot be hardcoded.
- OTP and one-time auth values
- credentials for non-public test accounts
- environment-specific feature toggles
When input is requested, provide exactly what is needed and continue run.
Input requests are expected in realistic auth and transaction flows. They do not mean the test failed.
Report reading framework
Use this simple triage grid.
| Signal | Meaning | Action |
|---|---|---|
| High pass rate + stable history | Healthy release candidate | Move to pre-release checks |
| Failures cluster in one area | Localized regression | Patch feature, rerun focused mode |
| Setup/connect failures dominate | Infra bridge issue | Validate extension and runtime path |
Reliability checklist before run
- Confirm extension is installed and active.
- Confirm preview URL is reachable.
- Select correct scope mode.
- Keep feature name specific when using focused mode.
- Avoid editing code during active run.
Common failure patterns
Pattern 1: run hangs in connecting
Usually extension or bridge path issue.
Pattern 2: tests start but no report produced
Often interrupted session or unhandled input request.
Pattern 3: false failures on stale preview
Preview URL changed but run used old endpoint.
Team operating model
For teams, assign testing ownership clearly.
- Builder owns feature implementation.
- Reviewer owns pre-release test confirmation.
- Release owner signs off on final report state.
This keeps accountability clean when runs fail near release windows.
Recovery workflow for broken runs
When runs fail for setup reasons, use this fast recovery path.
- restart extension and refresh preview.
- start a fresh test session.
- rerun same scope with same inputs.
- compare failure signature.
If signature changes, issue was likely setup path. If it remains, investigate product logic.
What to store from each critical run
- scope mode used
- feature name used
- report summary
- screenshot or artifact links
- final pass or fail decision
Keeping this data makes release decisions easier to justify later.
FAQ
Can I run without extension?
Some checks can run, but browser-level fidelity is limited.
Can I inspect old runs?
Yes. Session history stores prior run summaries and details.
Does every run produce screenshots?
Depends on flow and test mode settings. Browser pass steps can produce visual artifacts.
Should I run full-site every commit?
Usually no. Run feature mode during iteration, then full-site before release.
