jevwright
Browser tests written as user steps: Jev finds each control once, the path is recorded, and replays run without the model.
Overview
jevwright writes browser tests for business flows as the steps a user takes, with no selectors or page objects. It opens your app in Chromium and hands one step at a time to Jev, which picks the control the step refers to on the live page. The path found is recorded as a semantic target (role, name, nearby text, row), so later runs replay deterministically with no model calls and no cost in CI. When a recorded path goes stale, the step is grounded again and the recording updated.
The model never decides whether a test passed. A step is done when the request you declared succeeds, verify callbacks check business facts against your database or API, and implicit checks on every step catch uncaught exceptions, 5xx and unexpected 4xx responses, console errors, hydration mismatches and broken text such as undefined or NaN. Failures are classified as product, agent, environment, model or timeout, with screenshots, requests, Jev's decisions and a Playwright trace. It is published on npm.
What the decision model decides
| Type | Question | Answers |
|---|---|---|
| Choice | Which control on the page does this step mean (e.g. Save the profile)? | — |
How it works
- Define a test as act, verify, reload and check steps
- First run: Jev picks the control for each act step on the live page
- Path is recorded as a semantic target
- Code verifies declared requests and business facts
- Later runs replay without the model; stale steps are re-grounded
Strengths
- Pass or fail decided by code, not the model
- Free deterministic replays in CI
- Failures classified with evidence
- Implicit checks catch common breakages
Caveats
- Initial recording needs a TypeSafe key
- Semantic targets can go stale after redesigns
- Test quality depends on declared checks
Getting started
npm install @hazymoon/jevwright and define tests with defineTest, act, verify and check.At a glance
- Type
- Project
- Status
- beta
- Language
- TypeScript
- Runtime
- Node with Playwright/Chromium
- Has code
- yes
- Has tests
- yes
Use cases and integrations
How curated lists describe it
Browser tests for business flows written as the steps a user takes: the model finds each control once, and the recording replays without it.
MrJev/awesome-jev
Frequently asked questions
Does the model decide if a test passed?
No. Declared requests, verify callbacks and implicit checks decide.
Do replays cost money?
No, replay mode calls no model.
What happens after a UI redesign?
If the words on screen stay the same the test keeps working; stale steps are re-grounded and re-recorded.
Related projects
CodexQA browser skill that indexes in-page controls and has Jev pick the operation and target each step, with no screenshots needed.
Agent skillbetaGoal-driven browser agent where each step is one Jev choice over the page's controls, then reviews the run for root causes.
AppbetaTypeScriptChinese UI test framework where Jev scores candidate page elements for each step of a natural-language test case.
ProjectbetaPythonCucumber runner where Jev resolves each Gherkin step against the live page and Playwright executes it, so tests need only the .feature file.
ProjectbetaTypeScriptCommunity runner for Midscene Test adding jevAct, jevAssert and jevWaitFor nodes that use Jev over a bounded, non-text action space.
PluginbetaTypeScriptNode CLI for goal-driven E2E tests: Jev picks the next step from a code-generated action space, playwright-cli executes, code asserts.
CLIbetaJavaScript