Stop when element displayed

Stop a test early when a condition is met

The Stop when element is displayed step lets you end a test as soon as a specific condition appears, so you do not waste time running steps that can never succeed.

It is designed for situations where your application is clearly telling you something important, like an outage banner, a blocking modal, or a validation state that makes the rest of the journey irrelevant.

Stopping early means faster feedback, less noise in results, and less runner time spent on runs that are already decided.

What you can stop on

This step supports multiple stop conditions, depending on what you need to detect:

Stop based on a UI element

• Stop when an element is displayed

• Stop when an element is not displayed

This is ideal for banners, modals, overlays, error panels, and other UI signals.

Stop based on a value

You can stop when a value matches a condition, using common comparison types such as:

• Equals, Contains, Starts with, Ends with

• Has any value, Has no value

• Doesn’t equal, Doesn’t contain, Doesn’t start with, Doesn’t end with

• Greater than, Greater than or equal to

• Less than, Less than or equal to

• Custom regex

This is useful when the important signal is not purely visual, for example a status label, a dynamic message string, or a value you have stored during the test.

Why stopping early improves your test pack

Stopping early is one of the fastest ways to make a test suite feel more predictable and efficient.

It helps you:

• Avoid long chains of follow-on failures that all stem from one blocking issue

• Reduce wasted reruns when the environment is not in a usable state

• Keep results cleaner by ending at the true point of failure

• Preserve runner capacity for tests that can still deliver useful feedback

It is especially valuable in larger packs where one upstream issue can otherwise ruin dozens of tests.

Practical examples

Here are common situations where this step is a good fit:

Environment or service issues

If your application shows a banner like “some systems are down” or “maintenance in progress”, you can detect it and stop immediately, rather than letting every downstream step fail.

Blocking modals or forced interruptions

If your service displays modals such as:

• “A new version is available”

• “Your session has expired”

• “We have detected suspicious activity”

You can stop the test as soon as that modal appears.

Hard validation failures

If a message appears like:

• “We’re unable to process your order right now”

• “Payment declined”

• “Too many attempts, try again later”

Stopping early prevents wasted clicks and makes it obvious why the journey could not continue.

Shared account conflicts

If you reuse credentials and a message appears such as “another user has logged in”, you can stop instantly and treat it as a clear, actionable signal.

Best practice

Use Stop conditions for signals that are:

• unambiguous

• blocking

• actionable

That way, when a test stops, the output points directly to the real issue and saves everyone time.