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.
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 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.
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.
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.
Detection works across all JS frameworks.
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).
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.
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
<form> <label for="username">Username:</label> <input type="text" name="username" id="username"> </form>
Reflect can associate an
<input> element to either variant of
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.
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.
<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.
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.
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.
Shift+Tab keystrokes to change the focused element on the page, as well as any keyboard shortcuts implemented by the page authors.
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 (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:
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:
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:
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.
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.
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.
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.
Reflect supports the ability to dynamically, at test execution time, replace a designated string of characters with another string of characters or random text. This facilitates testing situations where new text input is required on every test run. For example, testing an account registration flow might require a unique (i.e., new) email address. While the email address could be unique during the recording, the first test execution will fail because the email address is already registered. In this case, Reflect can substitute a substring of the email address with random input to ensure that each test execution uses a new email address for registration.