Skip to main content
A test starts as a sentence in the project’s chat.

​
Write the instruction

Say what to do and what should be true at the end.
Two habits carry most of the weight:
  1. Name things you have actually seen on the page. “the Sign in button”, “the Email field”, “the cart badge”. Testorim does not know your site’s copy before it opens it.
  2. Say what “done” looks like. A test with no stated outcome can only check that nothing exploded.
Writing tests goes into this properly.

​
Choose the intent

Two controls sit next to the chat input.
Turn this on when the app is supposed to refuse. The run passes when the action is correctly rejected, and fails when it goes through.
If no step in the plan expects a refusal, Testorim appends one rather than letting a “should fail” test quietly pass because nothing was checked.
The default cap is 10 minutes. Raise it (5 to 120 minutes) for flows that legitimately take a long time: a scrape, an import, a background job you are waiting on.Raising the cap also stretches the step timeouts and the sweeper that reclaims dead runs, so a healthy 30-minute job is not cancelled mid-flight.

​
Send it

Press send. One of three things happens.
Steps appear in the execution bar and screenshots start streaming. Skip to Run and inspect a test.

​
Mid-run prompts

Some flows cannot be scripted ahead of time: a one-time code from an authenticator, an SMS code, a device-trust prompt. Ask for it in the instruction and Testorim will stop mid-run and wait for you:
The run parks for up to 10 minutes waiting for your reply, then continues with the value you gave. See Test data.
Mid-run prompts need a person watching. A scheduled run, a CI-triggered run or a fuzz variant has no input channel, so the step fails with that reason instead of hanging.

​
What gets saved

A chat message and its run are persisted whether the run passed or not, so the project’s history holds the failures too. Nothing is saved as a reusable test until you press Save as test. See Reusable flows.