Each activity gets added a subclass called TestTags containing attributes for all the tags. Those tags are then imported in the test classes. A feature called testTagsAsResourceId is used to allow interoperability with UI Automator for LoginActivity class.
It seemed to be the most viable option that combined:
Not wasting too much time declaring the tags (declaring them close to where they are used)
Having some kind of compiler check as to whether the test tags exist or not
Organizing the tags in a structured manner
There is no compile-time check for the declaration of the TestTags subclass, nor checks regarding its structure (it seems very hard to do such checks in Kotlin), but that was considered not enough of a downside to switch to other options such as declaring tags in a XML file and doing live parsing to recover the tags during tests, which are much less time efficient in my opinion.
Each activity gets added a subclass called TestTags containing attributes for all the tags. Those tags are then imported in the test classes. A feature called testTagsAsResourceId is used to allow interoperability with UI Automator for LoginActivity class.
It seemed to be the most viable option that combined:
There is no compile-time check for the declaration of the TestTags subclass, nor checks regarding its structure (it seems very hard to do such checks in Kotlin), but that was considered not enough of a downside to switch to other options such as declaring tags in a XML file and doing live parsing to recover the tags during tests, which are much less time efficient in my opinion.