Editing Test Steps in Robonito

Robonito allows you to modify recorded or manually created test steps using the Edit Event Node panel. Editing helps you refine selectors, adjust assertions, configure timeouts, and fine-tune test behavior for better reliability.

What Is an Event Node?

An Event Node represents a single test step within a test case. It represents one action or validation performed during execution.

An Event Node may represent:

  • Click
  • Input
  • Navigation
  • Assertion
  • Visual Assertion

Each step can be edited after recording or manual creation.

How to Edit a Step

To edit a test step:

  1. Open the test case.
  2. Locate the step in the step list.
  3. Click the Edit (✏️) icon next to the step.
  4. The Edit Event Node panel opens.

This panel allows you to modify the step configuration. Edit a Step

Edit Event Node Panel Overview

The Edit panel allows you to configure multiple properties of a step.

1. Event Type

Displays the type of step (for example, Assert).

This field indicates the category of action being performed.
It helps identify whether the step is a click, input, navigation, or assertion.

2. Timeout (in seconds)

Defines how long Robonito should wait before failing the step.

  • Default value: 10 seconds
  • Increase timeout for slow-loading elements
  • Decrease timeout for faster failure detection

Proper timeout configuration improves test stability.

3. Mark Optional

When enabled:

  • The step will not fail the test case if it fails
  • Execution continues to the next step

Use optional steps for:

  • Non-critical UI elements
  • Conditional elements
  • Flaky UI behaviors
  • Elements that may or may not appear

Avoid overusing this option, as it can hide real issues.

4. Description

A short explanation of what the step does.

Example:

Visually assert selected area

Adding meaningful descriptions improves readability and maintainability of test cases.

Assertion Configuration

If the step is an assertion, additional configuration options are available.

Assertion Type

Select the type of assertion from the dropdown menu. Assertion Type

The assertion type determines how Robonito evaluates the validation during execution.

Visual Assertion Example

If Assert visually same is selected:

Robonito compares the current UI snapshot with the stored baseline image.

If differences exceed the allowed tolerance, the step fails.

Tolerance

Defines the allowed difference between images in visual comparison.

Example: 0.1

  • Lower value → stricter comparison
  • Higher value → allows minor UI variations

Tolerance should be configured carefully to balance strictness and flexibility.

Snapshot URL

Displays the stored baseline image reference used for visual comparison.

This reference image is used to validate UI consistency across executions.

Visual Assert Info

Expanding Visual Assert Info displays detailed information about the selected validation area.

Includes:

  • Top
  • Bottom
  • Left
  • Right
  • Width
  • Height
  • X-coordinate
  • Y-coordinate

These values define the exact UI region being validated during visual comparison.

Selectors

Selectors define how Robonito identifies a UI element on the page.

You can:

  • View existing selectors
  • Add new selectors
  • Delete selectors
  • Copy selector values

Examples:

div >> internal:has-text="Quick" >> nth=0 body:nth-child(2) > main:nth-child(3) > div:nth-child(1)

Selector Best Practices

  • Use stable selectors
  • Avoid dynamic class names
  • Prefer unique attributes
  • Avoid overly long CSS paths
  • Validate selectors after recording

Stable selectors reduce flaky test failures.

Advanced Settings

The Advanced Settings section allows further customization of element behavior and matching logic (if applicable).

These settings help fine-tune how Robonito interacts with or validates an element.

HTML Element Info

Displays technical details of the selected element.

Example:

KeyValue
NameDIV

This information helps debug selector accuracy and understand the underlying DOM structure.

Step Status Indicator

After execution, each step displays its execution status.

Possible statuses:

  • PASSED
  • FAILED

Example:

FAILED – Visual assertion mismatch

If a step fails, you can edit and re-save the step to correct issues.

Saving Changes

After making modifications:

  • Click Save to apply changes
  • Click Cancel to discard changes

Changes are immediately reflected in the test case once saved.

Why Editing Is Important

Editing test steps helps you:

  • Improve selector stability
  • Adjust assertion strictness
  • Fix flaky tests
  • Increase timeout for slow elements
  • Refine visual validation areas
  • Make steps optional when appropriate

Proper editing improves reliability and maintainability of automation tests.

Best Practices

  • Always review selectors after recording
  • Increase timeout for slow-loading elements
  • Use tolerance carefully in visual assertions
  • Avoid overusing optional steps
  • Keep descriptions meaningful and clear
  • Test after modifying critical assertions

Following best practices ensures stable and maintainable test automation.