I’ve worked on some fairly large internationalized apps (50MM+ installs on each app) and on each app I’ve always had a problem with internationalization. It presents its own set of challenges. If you have not internationalized an app before you’ll quickly realize that your app design may not fit various locales – especially when text widgets are horizontally adjacent to each other. The text will eventually overlap or just look wonky and this can create odd UI bugs. You’ll find this out during testing, or as in my experience, when someone reports an odd text widget is overlapping another part of the UI. Finding these issues usually resulted in having your QA team go through each screen in the app to visually inspect the app for each locale. An optimal solution would be to visualize all of the different screens in the different locales so that it would be easy to inspect. Unfortunately that, solution did not exist …
While there is no silver bullet for this situation, there is a new tool that can help with this process (which also has ancillary uses as well).
I recently had the honor to work with the Fabric team – the same trusted team who brought us the Crashlytics tool that we all rely on. They were looking for some feedback on a new open source tool called screengrab. I got to try it out, and after some setup, I had an “Aha!” moment that made me want the tool immediately. It’s a tool that any pragmatic Android developer should evaluate as a possible candidate for their Android development toolbox – especially if your app is internationalized.
Let me explain why …
What is screengrab and why should I care?
Put simply, it is a command line tool that helps you take screenshots of your application at desired execution points in your functional android tests (Espresso) … in any locale.
A screenshot tool? Really? Any Locale? Why Should I care about that?
Therein lies the magic …
One thing you notice during the localization effort is that during design and development strings that fit in one language (English for me) do not necessarily translate well to other languages. Meaning that a five-letter word in English may translate to a twenty letter word in another language.
This is problematic when you are dealing with horizontal space. Longer text entries will overflow onto other widgets and you’ll have a problem.
As stated above, you often don’t realize it until it’s too late because manually testing your application on various locales is difficult and extremely time intensive.
How Does screengrab Help?
The screengrab tool will help automate the process of visually inspecting the various locale output of your app. You can configure screengrab to load up different locales, run all the UI tests and take screenshots during the execution of the test on various devices and configurations at the same time … and then ….
Screengrab will output all of the screenshot files for each locale for you. You can then use those files to quickly visually inspect if there are in fact visual problems with your application and locales.
Simply scroll through the files and check to see if anything is broken.
This can result in huge time savings when you make a feature change, add a new screen, etc.
How Do I Install It and Use it?
As usual, the Fabric team is making this as easy as possible. It’s one file to setup after the installation that anyone on your team can run once it’s checked into github (setup once, setup everyone forever).
Once installed you can start taking screenshots in your tests with the following Screengrab.screenshot(“screenshot_name”);
@Test public void testTakeScreenshot() { Screengrab.screenshot("before_button_click"); onView(withId(R.id.fab)).perform(click()); Screengrab.screenshot("after_button_click"); }
The above code is a jUnit 4 test that allows you to take a screenshot before an action with a the tag “before_button_click”. This tag will show up on the screenshot so you can trace the execution of your test and screenshots.
Then we click on a button, then take another screenshot.
Almost done …
Configuring Various Locales
Now, lets assume you have mulitpe locales and you want to test those various locales and see the screenshot results. To do that you’ll need to provide some configuration values in the screengrabfile.
The screengrabfile was generated when you installed screengrab. You’ll want to add the following information to the screengrab file:
# locales to test locales ['en-US', 'it-IT'] # clear all previously generated screenshots in your local output directory before creating new ones clear_previous_screenshots true
This configures screengrab to run the US Ensligh locale and the Italian locale.
Now Lets Run It
You’ll need to make sure you’ve built your application so that you have an application APK and the test APK. Build that with the following command:
$> ./gradlew assembleDebug assembleAndroidTest
Now that the application and test app are built you’re ready to kick off screengrab. Execute the following command:
$> screengrab
This will fire off your tests in each locale and you’ll see your device(s) reacting and your console going wild, as this gif showcases:
When screengrab is done your screenshots will be stored in the fastlane/metadata/android/images directory of where you ran the screengrab command.
View The Results
Viola! Open the file to see how everything went. Here’s an example:
What else can I use this for?
The screengrab tool integrates with the Ffastlane toolsuite right out of the box.
It’s fairly new for Android, so if you haven’t heard about it I totally get it. Here’s a quick synopsis – fastlane lets you, as a developer or release manager, automate your deployment pipeline. From integrating with continuous integration taking screenshots, to placing them into device frames (currently iOS only though, hopefully Android soon! Hint Hint Fabric team!), to upload the files to Google Play automatically. Fastlane helps you automate the deployment process of your Android apps. Check out fastlane for more detailed info.
The screengrab tool has a few additional use cases:
- Design/Product Manager Review
- Keep your product and design teams up to date with all of the screens in your application on a per build basis.
- Automate Screenshots for release
- Automate Screenshot automation for internal dog fooding and review processing with other tools.
- … and of course, to validate what might have gone wrong during a test.
Does this replace my other screen capture tooling?
No, screengrab complements the existing toolchain that is out there. If you need/want to use your other solutions, feel free to keep using it. Screengrab is just another tool in your toolbox.
Pragmatic Development Tooling
I’m very pragmatic in my day to day development. When I do internationalize my next app (which I’m actually doing in the next month or two) I will be reaching for screengrab as the tool to help sanity check my work.
Why?
It’s simple. It’s easy. It helps me solve a problem and it gets out of my way. I don’t need to write the tool myself. It just works.
As with anything new, it has a purpose and it now occupies a space in my toolbox. Maybe it will help you save some time too.
tbsprs says
Minor error: Your shell prompt shows up as
$>
.Diego Torres Milano says
AndroidViewClient/culebra (https://github.com/dtmilano/AndroidViewClient) also can automate the process of taking screenshots from external scripts and tests that can be generated by Culebra GUI (https://github.com/dtmilano/AndroidViewClient/wiki/Culebra-GUI) by point and click.
The screenshots can have device art, glare and drop shadow added automatically as described at http://dtmilano.blogspot.ca/2015/04/android-obtaining-beautiful-screenshots.html, and one of the best features to deal with the localization problem you describe is perhaps the ability of change the language using a single command (i.e `vc.uiDevice.changeLanguage(“en-rGB”)`).
Perhaps another nice addition to your toolbox.
Pedro says
I’ve recently seen a lint warning where there were two views horizontally aligned and horizontally wrapping content. The warning said something along the lines of “these two views might overlap in different locales”. Running this lint inspection before releases will help spotting some of these issues early 🙂
Christian Stanke says
But if you work with (professional) translators or even a LSP, how do you rely this information to them? How can they know, “just” from a screenshot which string needs revision? Will you have complete test coverage with automated UI test to spot all possible internationalization bugs/errors?
That were questions that we saw ourselves confronted with as we thought about possible solutions for contextualisation and linguistic QA processes. What we found is, that there is a whole lot more possible, if you build such screenshot automation tools from the ground up only with localization in mind. For example, grouping all strings on a given screen inside the translation editor automatically or marking the string position on screenshot interactive and use that for navigation.
We released this feature late last year and wrote a blog post to go along with it https://applanga.com/blog/in-context-and-linguistic-qa/
Let me know if you would be interested to learn more. Would be thrilled to give you, as somebody with the relevant experience, a demo
AICN.txt says
Is Screengrab.screenshot supposed to wait for idling resources in the way that Espresso view operations do? If not, your Screengrab.screenshot(“after_button_click”); capture will encounter race conditions.