Testing Modes

One engine, several ways to point it at your app. Each mode changes which actions Jevitate prefers — not how it verifies them.

Goal-directed testing

Give Jevitate a natural-language goal — "Create an account and verify the email", "Add a product to the cart and reach checkout". It continuously evaluates available actions relative to the goal and decides whether the goal was reached from observable application state — not because Jev returned DONE. It explores alternate paths when the obvious one is blocked, and changes strategy when repeated actions stop altering state.

jevitate explore --url http://localhost:3000 \
  --goal "Add a product to the cart and reach checkout" \
  --success urlIncludes:/checkout --real

Feature testing

Specify a capability instead of a sequence: "Test checkout", "Test team permissions". Jevitate discovers the relevant UI paths dynamically, exercises multiple valid routes, explores the boundary states around the feature, and records which states and transitions were actually hit. Scope it to routes with repeatable --route globs.

jevitate explore --url http://localhost:3000 \
  --feature checkout --route "/cart/**" --route "/checkout/**"

Exploratory testing

No predefined destination. Jevitate maintains a set of visited states and prefers actions likely to reach unseen ones, discovering undocumented paths while detecting dead ends and loops. The objective flips:

maximize(new_states + new_transitions + new_behaviors)

# rather than
minimize(actions_to_goal)

jevitate explore --url http://localhost:3000 --strategy exploratory --real

The run emits a coverage summary alongside the Recording; a discovered defect exits non-zero so it gates CI.

Adversarial testing

Adversarial mode intentionally searches for unexpected behavior. It prioritizes:

• Unusual but executable state transitions and ordering violations
• Repeated and rapid interactions
• Navigation during pending asynchronous operations
• Boundary input values and contradictory UI actions
• Alternate paths through multi-step workflows

All of it stays bounded by your configurable safety policy, and the stop decision comes from a trusted hard-signal oracle — never Jev's own claim.

jevitate explore --url http://localhost:3000 --strategy adversarial --real

Regression verification

Reproducible failures become deterministic artifacts: a minimized Recording that reproduces the smallest reliable trigger, asserts correct behavior (not the presence of the bug), and replays in CI without Jev. See Regression & CI.

Usability review

The usability strategy runs a UX review: ranked, evidence-cited findings that ask whether the user got the job done and where the experience gets in the way. Jev scores each screen against a cited rubric of Nielsen's heuristics, cognitive-science principles, dark-pattern detection, and a lightweight accessibility tier. Every finding names a real principle and anchors to observed behavior, so it stays advisory: it never sets a non-zero exit or gates a run. Calibrate it with --app-class (e.g. consumer, admin).

jevitate explore --url http://localhost:3000 \
  --strategy usability --goal "check out" --app-class consumer --real

It also runs offline over a saved Recording with jevitate ux <recording> --app-class. See MCP & CLI.

The strategy layer

Strategies are pluggable. The initial set:

Input strategies

TYPE_TEXT delegates to a configurable generator, and input values are chosen by field semantics — Jevitate never assumes every field should get arbitrary fuzz. Reusable strategies include normal, empty, boundary, long, unicode, whitespace, invalid format, duplicate, and previously used.

Loop prevention

Jevitate tracks visited states, state/action pairs, repeated transitions, consecutive no-ops, and time spent per state — with configurable limits on max steps, duration, repeated states, repeated actions, and model/network cost.