End-to-end tests that survive your next redesign.

Declarative flows for React Native that survive UI drift instead of breaking on it. When a test does fail, every failure ships with a verdict, a suspect commit, and a proposed fix.

v1·launched in march
flows/sign-in.flow.mdunchanged across all three
Enter the test fixtures, tap sign-in, then assert the home feed loads.
running on Sign In
fixtures/test-account.yamltest data
email: test@klera.io
password: hunter2-pass
9:41
Welcome back
Sign in to keep your trips synced.
test@klera.io
••••••••
Welcome back
Pick up where you left off.
test@klera.io
••••••••
Hi again.
Pick up where you left off.
test@klera.io
••••••••

Click any redesign — or build your own. The test never changes; the runtime adapts.

01self-healing under drift

Your tests heal themselves when the design changes.

When a button moves, gets renamed, or shifts component, the test finds it anyway and keeps going. The change is recorded as drift you can review on your own time — your flow file on disk stays untouched, your CI stays green.

flows/sign-in.flow.mdunchanged · committed once
# A returning user signs in

Open the app and tap **Sign In**.
Enter the test fixtures and confirm
the home feed loads.
runtime · v2 redesign
looking for "Sign In"
not where it was last time
found it labelled "Log in"
drift saved for review → __drift__/sign-in.json
flow passed · 1 drift, 0 failures
03 / parity
framework comparison

Where every framework agrees, and where they don't.

CapabilitykleraDetoxMaestroAppium
tap (by testID / label / text)
type text into input
swipe (direction or coordinate)
Hardware back (Android only)
Permission grant (Android runtime)
Visual regression diff
Network mocking + assertions
Self-healing strategy ladder
Run-time intent-drift recovery
Failure evidence capture
Auto-triage on failure
Proactive PR-time maintenance
supported partial not supported
See the full compatibility matrix →
02expanded analytics on every failure

Every failure ships with a full forensic record.

When a flow fails, the run captures the element graph, the final frames, and a link back to the change that caused it. A written narrative explains what happened, with confidence noted when the cause is ambiguous. You open the report and you know whether to revert a commit, update the flow, or rerun.

failureflows/checkout-android.flow.yamlstep 7 of 11 · failed at 00:12.4 · 2026-04-27
last frame · captured
verdict
regressiondriftflakedata

tap: "Place order" dispatched, but the next screen never mounted. The element graph shows the button transitioning to disabled — no navigation event followed.

suspect commit
a1c4f29checkout: gate submit on payment-method validity@miyu · 2h ago · packages/checkout/src/PlaceOrderButton.tsx · first flow run after this commit to fail
proposed fix · seed payment-method before tap
+ - setPaymentMethod: visa-test
  - tap: "Place order"
  - assert:
      visible: "Order received"
Open PR with this fix View element graph__failure-evidence__/checkout-android/14-22
03authored in prose

Write it like a script. Read it in a PR. Run it on a phone.

Flows are plain English (or YAML, if you prefer). Six lines describing what the user does — readable by your PM, reviewable in a diff, runnable on a real device. No JS or Swift authoring path, by design.

flows/dashboard.flow.mdprose · 4 lines
flow passed · 4 / 4 steps
06 / install

Try it on a flow tonight.

One command and a flows/ directory. Works against bare Expo and managed RN projects. Free, MIT licensed, no account.

$ npx klera-cli init