Reflect Docs

Supported Actions

Unlike other record-and-playback tools, you'll never have to manually enter a test step in Reflect. Instead, our test recorder is capable of automatically detecting a wide array of user actions, letting you create a regression test simply by interacting with your website.

Clicks

Among the most common of recorded actions are clicks. When recording a test, Reflect detects the element that was clicked as well as its (x,y) coordinates relative to the top-left of the clicked element. This enables us to accurately record scenarios in which the exact location of the click is important. One such example is Google Calendar. Within Google Calendar, each day within the “Week” calendar-view is represented by a single DOM element. This means that to accurately record a test wherein a meeting is created at a specific time of day, a click must be executed at the proper (x,y) coordinates representing that time of day.

Click coordinates for a given test step can be viewed within the Test Step Detail view for either a previous test run or an active recording.

Mobile Taps

Mobile web browsers will fire touch events rather than click events when users tap on an element on the page. For this reason, in mobile testing scenarios Reflect will leverage touch event APIs to record and execute taps instead of clicks.

Copy to Clipboard

If a click results in content being copied to the clipboard, Reflect will capture and display the copied contents. If on a subsequent test run the click does not result in a clipboard-copy, or if the clipboard contents do not match the expected value, the test will be marked as failed.

Hovers

Reflect is the only record-and-playback testing tool that detects hover actions automatically and only includes the hover actions relevant to the test. Like all other supported actions, hover detection is completely automated and requires no action on behalf of the user. As you record your test, Reflect monitors for hover actions that are required for the test to be repeatable. When a relevant hover action is detected, it is automatically inserted into the recorded set of test steps.

Consecutive hovers, such as hovering through primary, secondary, and tertiary navigation screens before clicking on an element, are also supported.

Reflect detects both CSS-based hovers (e.g. :hover) and Javascript-based hovers. Detection works across all JS frameworks.

Form Entry

Reflect detects interactions with all form entry elements, including checkboxes, radio buttons, dropdowns, text-areas, input boxes, and buttons. The metadata associated with each form element depends on the type of form element under test.

On the left rail, form entry test steps are organized under their common form parent (or under the body tag if no <form> tag is present).

WYSIWYG Elements

Edits to WYSIWYG elements (enabled via the contenteditable attribute) are detected and replicated in the Reflect test runner. These elements are typically outside of a <form> element and so are recorded as standalone test steps.

Labels

Form elements can optionally have an associated label. Labels can be defined in the HTML either as an enclosing element:

<label>
  Username: <input type="text" name="username">
</label>

or as an element associated with a form element via the for attribute:

<form>
  <label for="username">Username:</label>
  <input type="text" name="username" id="username">
</form>

Reflect can associate an <input> element to either variant of <label>. When detected, the label value associated with the form element will be displayed in the test plan on the left rail as well as in the Expected Label section when clicking on a test step.

The ‘value’ property

Most form elements contain a value property, whose meaning depends on the type of form element being interacted with. As such, Reflect will treat the value of a form element differently depending on what element is under test.

With form elements such as <input type="text"> and <textarea>, the value represents the text that’s visible within the element, and so Reflect will populate this value in the Expected Text section.

With form elements like <input type="checkbox">, the value represents an internal value that is not visible on the page, and so in this case Reflect will populate the value in the Attributes section.

Lastly, the <input type="file"> does not have a meaningful value and the <input type="image"> does not define a value property at all. We ignore the value property entirely for these form elements.

Scrolling

User-initiated scrolls are detected and will be exactly replicated in your tests. Scrolls that occur automatically (such as visiting a link with a # fragment in the URL) are not initiated by the user and thus will not be recorded. Similarly, scrolls that occur indirectly as a result of a user action (such as clicking on a ‘Back to Top’ button) are not recorded as they are initiated from a previously recorded action (in this case, clicking ‘Back to Top’).

In addition to scrolls that occur on the main document, Reflect detects and records scrolls inside scrollable child elements.

Finally, Reflect supports and enables scroll into view by default on all test steps. This feature detects when elements are on the page but out-of-view, and scrolls the element into view automatically before interacting with it.

Keypresses

In addition to detection of keypresses within input text elements, text-areas, and contenteditable WYSIWYG elements, Reflect also detects other types of keypresses that change the state of the page. This includes Tab or Shift+Tab keystrokes to change the focused element on the page, as well as any keyboard shortcuts implemented by the page authors.

Note: Reflect currently restricts keypresses to either a single key, or a combination of Shift + an arbitrary key. Other keyboard combinations are currently blocked in the recorder and are not supported.

Back / Forward / Refresh

Browser navigation is exposed within the Reflect recorder and is replicated in the Reflect test runner. Browser navigation works for both Single Page Applications (SPAs) and non-SPAs.

Drag and Drop

Drag-and-drop (DnD) actions recorded in Reflect will playback in a test using the same mouse gestures used in the original recording. This allows for accurate recording of complex DnD actions of arbitrary length and duration. In the example below, Reflect is able to create a pixel-perfect replica of the following image created in an online MSPaint-like app:

Reflect’s drag and drop detection works for both native HTML5 DnD implementations and Javascript-based DnD libraries, including popular libraries such as:

Click and Drag

The same logic that powers drag-and-drop support also enables you to test click-and-drag behavior, which is a different but related action. Supported click-and-drag examples include:

  • Resizing a textarea
  • Moving a slider to a different position
Note: To preserve test fidelity, the ability to click-and-drag to select text is disabled within Reflect recording sessions.
Swiping

For mobile tests, Reflect will detect and replicate swipes using the same detection logic underpinning drag-and-drops and click-and-drags. Examples of swipe-enabled elements include:

  • Mobile carousels
  • Slide shows
  • “Cover Flow” effects

File Upload

When you click on a <input type="file"> element or interact with any element that would normally trigger a native filepicker modal, Reflect will intercept the action and will prompt you to select a file from your local filesystem.

After selecting a file and clicking Upload, we’ll inject your file into the recording session and save a copy of the file for use in subsequent test runs.

You can access upload files at any time by selecting a test run, choosing the test step containing the file upload, and clicking “Download File” from the Test Step Detail view.

Note: File uploads are capped at 10MB. If you require a higher limit, please email support@reflect.run.

Native Alerts

Native alerts are modal dialogs that use the native OS chrome rather than custom-styled DOM elements. The following native alerts are detected and recorded by Reflect:

  • alert(): Displays a message and a single ‘OK’ button.
  • confirm(): Displays a message and both an ‘OK’ and ‘Cancel’ button.
  • prompt(): Displays a message, an input box, and both ‘OK’ and ‘Cancel’ buttons.
Note: Dialogs defined within a beforeunload event callback, as described in this MDN article, are not currently supported.

Reflect validates both the presence of the modal dialog, as well as its text content and user selection. As such, Reflect automatically validates the correctness of these native OS alerts so that you do not need to use a Visual Observe on these dialog boxes, which could lead to false positive failures when executing tests across different browsers.

IFrames

Reflect includes robust support for iframes which is completely automated for you. When recording a test, Reflect detects if you are interacting with an element inside of an iframe. When it retrieves the selectors for elements within an iframe, it also retrieves the selectors that target the containing iframe.

When the test runs, Reflect first attempts to locate the containing iframe, and, once found, attempts to locate the selector of the interacted element that is inside of the iframe.

As iframes can be nested within other iframes, Reflect supports retrieving elements within nested iframes at an arbitrary level of depth.

Copyright © 2020 Reflect Software LLC. All Rights Reserved.