Scrolls and Swipes

Scrolls and Swipes

testRigor supports scrolling and swiping in all 4 directions: up, down, left right

You can also scroll partially (½, ¼, up to an eighth) for better accuracy and speed of execution:
scroll up by 1/4 of the screen
Or start scrolling from a specific part of the page:
scroll up on “Contact Us”

Swiping is the mobile equivalent of scrolling. However, the direction describes the finger movement rather than the page movement.
For example, swiping up moves the page down, while scrolling down moves the page down. Swipe up = scroll down.

Scrolling in a loop

testRigor supports loops to perform repetitive or reiterative actions.
You can use the keyword until to repeatedly scroll until a specific element or value appears:
scroll up until page contains “Place order”
By default, testRigor will attempt loops up to 10 times if undefined. However, users can define loops to occur between 2 and 42 times with the words up to.
scroll down up to 30 times until page contains “Place order”

Note: The scroll until page contains method works best in Visible first mode.

Visible first prioritizes only what is visible in the viewport/screenshot.
Batched mode opens testRigor’s visibility to anything that is loaded on the page whether it is visible to the end user or not.

To toggle this setting, you can find the dropdown in Settings -> Speed optimizations -> Performance -> Getting visibility of elements approach.

Targeted Scrolling

Screen location can be put in two different categories: scrolling inside scrollable containers and scrolling on a specific element.

Scrolling inside scrollable containers

When the screen has several scrollable areas and we need to scroll inside of it without moving the page itself, we target the container/div with the content we need to move into view and perform the scroll.

scroll down on "myDiv" until "element" is visible

Scrolling on a specific element

When the screen has several compartments and we need to scroll on an area without being confined to a container/div, we can target something on the screen and scroll on a loop using the mouse.

scroll down on "element1" up to 10 times until "element2" is visible using the mouse

Note: Notice that when scrolling using the mouse, a limit must be set for the loop.

Scrolling using the mouse

By default, testRigor handles scrolling through JavaScript. Adding using the mouse simulates scrolling with a physical mouse wheel instead.

scroll down on "text" until page contains "Sign here!" using the mouse
scroll down on "text" using the mouse until page contains "Sign here!"

Automatic Scrolling

If a targeted element is outside the current viewport/screen, testRigor automatically scrolls to bring it into view, typically positioning it near the center of the screen.

Imagine a Submit button is farther down the page and currently isn’t visible on your screen. You can still write:

click "Submit"

testRigor will automatically scroll down until "Submit" is visible, then click it. This applies to elements targeted by click, hover, enter, and validation commands, as well as anchors used in relative locations. Relative-location anchors have the highest priority for automatic scrolling.

Auto-scrolling can be changed under Settings → Speed optimizations.

The without scrolling keyword prevents testRigor from automatically scrolling the page to bring the targeted element into view. This is useful for addressing individual cases where you want to disable automatic scrolling without changing the setting for the entire test suite

Screenshot behavior for scrolling

Like click, drag and hover commands, each manual scroll command triggers a new screenshot.

However, automatic scrolling does not trigger a screenshot. This means the page may move between commands without a new screenshot being captured, so validation highlights may sometimes appear in unexpected positions in the next screenshot.

For example:
1. An enter command automatically scrolls down to an input.
2. The next validation check that automatically scrolls somewhere else.
3. Neither automatic scroll necessarily creates its own screenshot. The command itself may still capture one (enter, check that)
4. When testRigor eventually takes the next screenshot, the page may now be at a different position.

Using AI to scroll on elements 

You can use AI to scroll within specific sub-sections or areas of the UI.

Example:

scroll down on "left menu list" using ai

Here, "left menu list" is the prompt given to AI. AI uses both the page source and screenshot to locate the specified element or area, which in this case likely refers to a scrollable menu on the left-hand side of the screen.

AI is only responsible for identifying the target element/area, the scroll action itself is performed by testRigor.

You can also use AI within scroll commands in combination with loops to progressively scroll until a specific element is found.

Example:

scroll down until page contains "Contact Us" using ai

In this case, the scroll action is executed while AI is used to detect whether "Contact Us" is present on the page. If it is not found, the scroll continues until the element is located.

Test your knowledge

scroll up until visible “Place order”
scroll up until page contains “Place order”
scroll up until “Place order” is on top
scroll up until “Place order” is loaded
Batched mode
Scrolling first mode
Visible first mode
Mouse wheel mode