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 journey 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.
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.
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)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.
Regression verification
Reproducible failures become deterministic artifacts: minimal Playwright tests that reproduce the smallest reliable trigger, assert correct behavior (not the presence of the bug), and run in CI without Jev. See Regression & CI.
The strategy layer
Strategies are pluggable. The initial set:
| Strategy | Prefers |
|---|---|
goal | Actions likely to advance a declared objective |
explore | Actions likely to expose new application states |
adversarial | Unusual transitions, boundaries, ordering violations, fragile states |
coverage | Actions that expand known state-transition coverage |
regression | Actions related to previously discovered failure paths |
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.