Enhancer

The Enhancer module receives as input a 2nd generation test script, written according to a given syntax, and parses it in order to find the operations that are performed inside it and add calls to the TOGGLETools Android library, to perform at execution time the extraction of the information needed for the translation.

The Enhancer is primarily tailored to identify Espresso interactions that are defined starting with an onView ViewInteraction, which is the primary interface – offered by the tool – to perform interactions and assertions on individual widgets

of the GUI. The onView method receives as parameter a ViewMatcher, and each Matcher finds views in the visual hierarchy according to a specific property that can be defined for the view (i.e., IDs, text content, content description). After a view is identified, Espresso allows performing operations on it with the perform method, to which a ViewAction is passed. Each ViewAction is specific to a kind of interaction that can be performed on the identified view (e.g., click, double click, insertion or modification of contained text).

The inspection of Espresso test cases has been performed using the JavaParser library1, identifying method calls corresponding to Espresso ViewMatchers, ViewAc- tions, and ViewAssertions. Currently, the Enhancer supports most of the interactions (each defined by a ViewAction class) that are supported by Espresso, except for the ScrollTo and pressIMEActionButton commands. For what concerns the ViewAsser- tions, only the isVisible assertion (that checks if a given element appears on screen) has been taken, by now, into consideration by the Enhancer and hence by the follow- ing translation phase.

Each time an instruction starting with onView is identified in the code of the test script, the Espresso Enhancer adds calls to three different methods of the TOG- GLETools library right before the execution of the operation, to capture information about the screen hierarchy and the actual graphic appearance of the current activity. Specifically, calls to the following methods are added:

TakeScreenCapture The method, whose prototype is

p u b l i c s t a t i c B i t m a p T a k e S c r e e n C a p t u r e ( D a t e c u r r _ t i m e , A c t i v i t y a c t i v i t y ) ,

receives as parameters the current time, and an instance of the current activity. It takes a capture of the current screen of the application, which is returned in a Bitmap file and saved in the external storage of the Android Virtual Device, named after the current timestamp of the Android device.

DumpScreen The method, whose prototype is

p u b l i c s t a t i c S t r i n g DumpScreen ( D a t e c u r r _ t i m e , U i D e v i c e d e v i c e ) ,

9.2 Layout-based to Visual Translator Architecture 129

receives as parameters the current time, and an instance of the UiDevice class of the UIAutomator library. It takes a dump (a .xml description of the layout) of the current activity and saves it in the external storage of the Android Virtual Device, named after the current timestamp of the Android device.

LogInteraction The method, whose prototype is

p u b l i c s t a t i c v o i d L o g I n t e r a c t i o n ( D a t e c u r r _ t i m e , S t r i n g s e a r c h _ t y p e , S t r i n g s e a r c h _ k e y w o r d ,

S t r i n g i n t e r a c t i o n _ t y p e , S t r i n g i n t e r a c t i o n _ p a r a m s ) ,

uses the built-in LogCat tool to Log information about the operation that is performed, and the way the element of the screen has been identified. The search_typeparameter identifies the type of search that has been performed (e.g., "id", "text", "content-desc"); the search_keyword is the specific keyword that has been searched in the layout to identify the view on which to operate; the interaction_type identifies the operation that is performed on the view (e.g., "click", "type-text"); the interaction_params string contains optional parameters (divided by a ";" character if multiple) that may be needed to describe the performed interaction (e.g., the text to type in case of "type-text" interaction).

The information is logged using the Log.d built-in function, adding the "TOG- GLELOG" keyword to allow subsequent filtering of the lines of interest from the complete log that is relative to the application.

The logged arguments for the translated interaction types are reported in table 9.4. Appendix C reports details about the operations performed by the translated Espresso commands.

The output of the Enhancer module is an Enhanced 2nd Generation Test Script, which can be executed as a normal test on the application run in the Android Virtual Device, but that is now able to trigger the collection of the information to the translation, in addition to execute all the steps of the original test case.

Figure 9.5 and 9.6 show a sample excerpt of a test file, respectively in its original form and in the enhanced form after the use of the Enhancer module.

The Enhancer module also adds checks according to the check operations that are present in the original test case. A check for the appearance of the whole screen

Table 9.4 TOGGLE - Enhancer: Arguments for translated interaction types Espresso interaction Arguments

clearText() i. Text length

click() None

closeSoftKeyboard() None doubleClick() None longClick() None openActionBarOverflowOrOptionsMenu(Context context) None openContextualActionModeOverflowMenu() None pressBack() None pressBackUnconditionally() None

pressKey(int keyCode) i. Keycode pressKey(EspressoKey key) i. Keycode

pressMenuKey None

replaceText(String stringToBeSet) i. Text Length; ii. stringToBeSet swipeDown() None

swipeLeft() None swipeRight() None swipeUp() None typeText (String stringToBeTyped) i. stringToBeTyped typeTextIntoFocusedView(String stringToBeTyped) i. stringToBeTyped

9.2 Layout-based to Visual Translator Architecture 131

Name Size (inches) Resolution (pixels) Density Pixel XL 5,5” 1440x2560 560dpi Pixel 2 XL 5,99” 1440x2880 560dpi Pixel 2 5,0” 1080x1920 420dpi Pixel 5,0” 1080x1920 xxhdpi Nexus S 4,0” 480x800 hddpi

Nexus One 3,7” 480x800 hddpi

Nexus 6P 5,7” 1440x2560 560dpi

Nexus 6 5,96” 1440x2560 560dpi

Nexus 5X 5,2” 1080x1920 420dpi

Nexus 5 4,95” 1080x1920 xxhdpi

Nexus 4 4,7” 768x1280 xhdpi

Galaxy Nexus 4,65” 720x1080 xhdpi

Table 9.5 TOGGLE: devices supported by the Executor for test case execution

is added by default at the end of the test case. This is a design decision that has been made in order to have a check of the final state of the GUI at the end of each translated test execution. Visual testing tools, in fact, may perform mouse operations on wrong elements of the screen, if the image recognition engine they use mismatches a portion of the screen with a given screen capture. In those cases, if there are no explicit checks after those wrong interactions, the test case is considered passing. On the other hand, it is highly likely that interactions on wrong parts of the user screen lead to a final state of the application that is different from the one reached after the execution of the original 2nd-generation test script. A final check using the full screen of the app as an oracle is hence an added layer of robustness for the generated test case.