Has anyone tried using external automation tools (...
# compose
m
Has anyone tried using external automation tools (like appium) to drive the interaction with a material3 NavigationBar and NavigationBarItem. The issue i'm having is that these controls clear and handle their own semantics, and as a result, the
testTagsAsResourceId
doesn't actually expose the accessibility property for the viewIdResourceName. The only aternative i've seen suggested is selecting by text or content description, which isn't ideal as that changes from language to language.
p
Hey @mattinger — that is a fundamental limitation with external black-box tools like Appium. Material 3
NavigationBarItem
(and several other M3 components) merges and clears semantics internally, which causes Compose's platform accessibility bridge to drop
testTagsAsResourceId
from the OS-level
AccessibilityNodeInfo
. Since Appium only sees the external OS accessibility tree, it forces you into matching localized text or content descriptions. I built Parikshan (github.com/aryapreetam/parikshan) to solve this exact issue. Instead of relying on OS accessibility exports and
testTagsAsResourceId
, Parikshan interacts directly with Compose's internal unmerged semantics tree (
useUnmergedTree = true
). Any
Modifier.testTag(...)
you set on
NavigationBarItem
works natively without depending on locale-specific text:
Copy code
e2eTest {                                                                                                       
  click(tag("nav_profile"))                                                                                             
  assertVisible(tag("profile_screen"))                                                                                        
}
It also runs the exact same test suite across Android, iOS, Desktop, and Web. Happy to help if you'd like to try it out or need a quick setup sample for your navigation bar.
m
Thanks. Unfortunately, i don't have much of a say in the external tools used. Those are evaluated and chosen by our larger QA organization. They're mostly using a combination of appium and/or maestro, so a new framework is not an option.
But it's very concerning that the material library handles things in this way that hinders the usage of external tools like this.
p
Fair enough. If you just need an unblocking hack so Appium/Maestro doesn't have to rely on localized text, the common workaround in Compose is wrapping each item in a dummy Box:
Copy code
Box(Modifier.semantics { testTagsAsResourceId = true }.testTag("nav_item_home")) {                                                                   
  NavigationBarItem(...)                                                                                               
}
It's a bit of a layout smell, but because the Box sits above NavigationBarItem in the tree, Compose exposes the viewIdResourceName on its accessibility node before M3's internal semantics clearing takes over. And yeah, completely agreed on M3—Google has had an open ticket on this exact clearAndSetSemantics behavior breaking accessibility tools for a while: issuetracker.google.com/issues/304199047