Currently the components in components (e.g. Scanner.tsx, Cropper.tsx, ResultViewer.tsx) don't expose any testID props. When writing end-to-end tests with Appium, there are no stable identifiers to target elements. We're forced to locate elements by their visible text / auto-generated accessibilityLabel, which is brittle — it breaks when copy changes or is localized, and it doesn't work at all for non-text controls like the camera view.
Suggestion
Add testID props to the key interactive/UI elements so they can be reliably located in automated tests. On iOS testID maps to accessibilityIdentifier (Appium accessibility id), and on Android it maps to resource-id.
Ideal features
Allow consumers to override or supply testIDs via component props, rather than hardcoding, so downstream apps can namespace them.
Consistent, documented naming convention (e.g. scanner-camera, white-background-switch).
Currently the components in components (e.g. Scanner.tsx, Cropper.tsx, ResultViewer.tsx) don't expose any testID props. When writing end-to-end tests with Appium, there are no stable identifiers to target elements. We're forced to locate elements by their visible text / auto-generated accessibilityLabel, which is brittle — it breaks when copy changes or is localized, and it doesn't work at all for non-text controls like the camera view.
Suggestion
Add testID props to the key interactive/UI elements so they can be reliably located in automated tests. On iOS testID maps to accessibilityIdentifier (Appium accessibility id), and on Android it maps to resource-id.
Ideal features
Allow consumers to override or supply testIDs via component props, rather than hardcoding, so downstream apps can namespace them.
Consistent, documented naming convention (e.g. scanner-camera, white-background-switch).