Asserting text — without hardcoding strings in android through appium, wd

A frequent challenge in automation is to create assertions that are flexible and maintainable. For instance, in the following screen if I want to assert that the text of the ‘Send’ button in fact ‘Send’

my code would look something like this

let send_logs_button = await driver.elementById(screens.settings.sendLogs);
let send_logs_text = await send_logs_button.text();
send_logs_text.should.equa(“Send”);

But it has 2 problems:

1. Internationalization- How to run the test in a different language. We have to maintain a map of each language and the string.
2. Maintainance- What happens when Send changes to say Sent. We would have to find all the places in test code where we are referencing Send and update to Sent.

Only if there is a way to get the latest strings used by the app in the current language, fortunately there is!
The apk that is used for automation also has all the strings along with it in a xml file and more conveniently appium has this built in method to extract the strings.xml in appium-android-driver called getStrings and I can invoke it in wd with getAppStrings.

Hence my code will look like this:

let send_logs_button = await driver.elementById(screens.settings.sendLogs);
let send_logs_text = await send_logs_button.text();
let app_strings = await driver.getAppStrings(language);
send_logs_text.should.equal(app_strings.settings_send);

A perceptive reader might observe that we our automation’s source of truth comes from the SUT which in our case is the APK but the distinction here is that we are only asserting that these strings in fact do show up in the place that we expect them.

One gotcha to observe here is that when specifying locales one has to match exactly the values folder for the corresponding language. For instance for zh-rTW our getAppStrings should be called with “zh-rTW”, if you use zh-TW the system would default to english and the assertions would fail.