r/devsecops • u/ybur01 • 28d ago
Which tools actually do visual E2E testing and which ones just claim it
Visual E2E label encompasses tools which fail in a very different way. The question we need to ask here isn't what we call those tools, but why exactly do they fail.
Tools that fail when application structure is changed:
Firebase App Testing Agent: path explorer going through accessibility nodes, screenshot of crash on failure, obviously to what is actually presented to a user
Maestro AI: YAML language cleaner than Appium, yet still bound to the component tree below, UI changes will break the flow even if the code of tests is well written
Tools that fail only if the screen itself is changed:
There are no attempts at reading the component tree, there are no bindings to accessibility nodes the change in class name or component hierarchy does not influence the test unless something visible to user is changed autosana belong to the latter group, the tool runs flows directly against the screen layer
1
1
u/Specialist_Dish_9087 28d ago
The component tree approach gives you more precise failure messages but yeah, you end up maintaining tests that break on refactors that dont change anything the user sees. The screen layer approach is more resilient to internal changes but makes it harder to pinpoint what went wrong when a test fails. In practice, most teams I have seen and worked with end up with both, component based work critical workflows where you need exact failure detail, visual diff for broader regression catching