By default, mabl clicks an element even when it's disabled, hidden, covered by another element, or still moving on the page. That behavior is convenient, but it can hide real bugs: a test passes on a button that a real user could never click. You can now turn on actionability checks so a click step fails when its target isn't actionable, and you can control that behavior for a whole application or for a single step.
An element is actionable when it is:
- Enabled: not disabled
- Visible: not hidden
- Unobstructed: not covered by another element
- Stable: not animating or moving
How it works
Actionability checks have two levels of control:
- Application default. On the Application edit page, set whether new click steps check for actionability. That default is what mabl uses whenever you record or add a new click step for that application. The setting appears in an Actionability checks section, alongside the enter-text behavior setting.
- Per step. In the mabl Trainer, each click step has its own actionability setting that overrides the application default. Open a click step's edit view to change it.
The application-level actionability checks setting acts as a default for new click steps as you author them. Changing it does not retroactively update steps you've already created, though you can always edit steps individually. At execution, mabl reads only the per-step value.
Try it out
To author click steps with actionability checks, use the latest version of the mabl Desktop App.
- Open the application you want to configure and edit its settings.
- Set the default actionability behavior for new click steps.
- In the Trainer, record or edit a click step. New steps pick up the application default; adjust the per-step setting when a specific step needs different behavior.
- Run the test. A click step with actionability checks on fails if the target element isn't actionable, instead of clicking it anyway.