Capture an element’s current output into your test results
When building and troubleshooting automated tests, visibility into what the browser actually sees at a given moment can be incredibly helpful. The Debug Element step lets your automation capture diagnostic information about a specific element during a run and include that data in your test results.
This is especially useful when a test is failing unexpectedly, when selectors behave inconsistently, or when you need extra context for a flaky interaction.
Why debug information matters
Automated tests often fail because an element’s state is different than expected. For example:
The element is present but empty
Text or values differ from what you anticipated
Visibility or layout changed
Dynamic data makes assertions brittle
Selectors match multiple elements
Without insight into what the browser actually sees at that point, diagnosing failures can be slow.
The Debug Element step gives you a snapshot of the element’s state so you can understand what your automation encountered.
What the step captures
When this step runs, it collects information about the target element including:
The rendered text
Attribute values (like classes, ids, roles)
Inner HTML
Computed styles
Visibility state
Any other relevant DOM information
This data is then attached to the test result so you can review it later in context.
How this helps with troubleshooting
Instead of guessing why a selector failed or why an assertion did not fire, you can use debug output to:
Confirm the element exists
See what text was actually present
Validate attribute or state differences
Identify unexpected whitespace or formatting
Compare expected vs actual real output
Understand timing issues or asynchronous state
This reduces guesswork and accelerates resolution of issues in your test pack.
Use during development and maintenance
Debug Element is best used when:
Building a new test
Investigating regression failures
Validating selector accuracy
Diagnosing flaky assertions
Reviewing how UI state changes over time
Once your test is stable, you can keep or remove debug steps depending on how useful the captured information remains.
Combine with assertions and flow inspection
You can place a Debug Element step immediately before or after:
Check Text
Check Value
Check Exists
Check Displayed
Wait for Element
Touch
This way you capture the state right when it matters most, giving you precise context for subsequent actions or assertions.
Including targeted debug output in results turns your automation into not just a pass/fail signal, but a rich source of insight into how your UI behaves during execution.