Hi all. I'm working on a Compose project and have ...

# compose

[Bam]

Hi all. I'm working on a Compose project and have gotten to stage where I need to introduce Instrumentation testing (for Android).
I instinctively reached for .testTag(...), but did a little search to see if any new tools, best practices, approaches, etc, had been introduced. To my surprise, and also reluctant agreement, I see advice against the use of .testTag(...) being the go-to solution for testing Compose.
Strong argument against: https://proandroiddev.com/stop-using-test-tags-in-the-jetpack-compose-production-code-b98e2679221f
Milder argument against: https://callmeryan.medium.com/efficient-testing-or-code-pollution-the-role-of-testtag-in-jetpack-compose-testing-4892ee73e966

I also want as clean production code as possible, and if I can find a way to not introduce testTag everywhere in my code, I would love that.
Want to get people thoughts and see what everyone is doing for Compose instrumentation testing.

[jw]

Strong agree. This isn't new, as well. Using IDs for view testing has also been a smell forever. It means you're relying on implementation detail. A test should read and behave as if you are telling another human what to do as they're holding the phone. That means relying on visible things (including accessibility things).

[Bam]

So my plan will be to attempt to relay on .testTag(...) as a last resort, favouring instead:
• Actual text in elements, potentially leveraging String resources, which would allow me to do testing on multiple languages. 🤔
• ContentDescriptions, which is essentially how ScreenReaders work for accessibility. This will also force me to set useful ContentDescriptions for things. Will need to investigate best practices to not go overboard.
• Semantics using the states provided by the ViewModels (where it's reasonable to do so).
• And good old tree navigation. "Look for the button with X, under the field with Y, above the text with Z".
I've never encountered the Role description for a Composable, but might also be something for me to look into.

Feel free to throw any other suggestions at me if anyone has any. 🙏🏼

[jw]

Yeah that's a great list

[David]

Thanks for sharing, have encountered this in our code base and always felt a bit off with test tags.

[christian.steffensen]

What is the ideal solution in an app where every UI label(and associated a11y description) is controlled in a CMS, so we can't reliably test against those actual values?

[jw]

Your tests should use fixed local copies of data so the screens never change. After all you want to test your logic which maps the data models into UI models and associated behavior. You don't need to test the actual CMS.

[jw]

And presumably the CMS sends JSON or some other data format, whose deserialization can be separately unit tested using golden values to expected data models.

[jw]

The actual CMS and its data should never factor into the tests

[christian.steffensen]

Good point, thanks :)