When recording test actions, reflow collects large numbers of data points on the underlying element that's been interacted with.

When replaying a test action, reflow will intelligently look for the appropriate element to interact with by combining these data points, using multiple strategies together to beat non-determinism. It will:

  1. Wait until the network is idle (or a timeout)
  2. Wait until the page looks similar to how it looked when the test action was captured (or a timeout)
  3. Evaluate the Preferred Selector
  4. If the preferred selector is found, unique, and appropriate (e.g. a "click" action will not work on elements with the attribute "disabled"), select that element
  5. Else, within a score-limit, rank all possible selectors for that element and its parents, evaluate these selectors based on their specificity, and if a statistically likely common element comes out, and it visually looks like the recorded element, pick that one.
  6. If no statistically likely common element can be found within the score limit, increase the score limit and try again, caching prior responses and appending prior results until a clear winner comes out.

With this process, Reflow is highly likely to always select the same element between tests on an arbitrary website. If there are issues, then high specificity attributes are recommended to be added to the element or its parents to help reflow always select the same one.

In order, reflow scores specificity roughly as follows in the table below (lower score means higher specificity). This scoring is applied recursively from an element until the root of its DOM/Shadow DOM node. nth-child is used to combine parent and child selectors, should it not be a uniquely identified subelement when combined with a parent selector.

Element AttributeScore
data-testid or data-test-id or data-test1
First 80 characters of element inner text30
Element Node Name200
Minimal Combined Class Name that's unique in page200
Ignore element and evaluate all parent selectors instead1000 + SUM(parent selector)
Wildcard Fallback (any element)10000000

Auto Healing

When the web page updates in such a way that the element changes, the new element selector hierarchy is collected during the test run using the specificity rules above. Should the test succeed, subsequent tests will use the most recent successful run to guide element selection.

Due to this, as long as changes are relatively small over time, the test will auto-heal interactions where a manually written test would require additional work to fix.

For example, if a software release changed an anchor node (link) into a button, but one of the following is true: [kept in the same element hierarchy, kept the same text, kept the same [data-test-id] etc], the test would continue working, and update itself appropriately without user interaction.

If the auto-healing process does not work, the test can be debugged in the edit screen, by clicking "Play" then waiting until the error is replicated. At this point, delete the original step and re-record it, then save the test (or press "Play" again to fully validate the test).

© 2021 Resilient Software Ltd