Problem: Use Appium and press ‘Enter’ on the soft keyboard.
This post continues our series on intermediate level problems when automating mobile application tests using Appium. We thought of sending a KeyEvent to an input (textbox) element using Appium. Superficially this appears to be trivial, but while writing the script, figured out otherwise. To our surprise, it failed. And there seems to be a good reason for it too! The rest of this post outlines what we were trying to do, what we learnt and what we (reluctantly) ended up doing.
Why this post?
Qxf2’s top goal is to help testers. We identified mobile automation as one area where we could help testers. Over the past few months, we have written several basic tutorials that help testers with mobile automation. We feel like the next stage is to address some common intermediate level problems you may face as you implement mobile automation at your workplace. Over the next few posts, we will tackle some common technical challenges testers are likely to face and our approach to solve them.
New to mobile automation?
If you are new to mobile automation, we suggest the following posts to get started:
a) Run Appium on an emulator
b) Run Appium on mobile devices
c) Identify UI elements on mobile platforms
d) Execute different mobile gestures
As with our earlier post, we continue to use BigBasket as the application under test. This post deals with an issue we faced while writing the tests scripts for search functionality. We entered a string in the search box. In this particular application, once we enter the text to be searched, a soft keyboard appears with the search icon instead of the enter button. Turns out for BigBasket, the search icon cannot be identified by an xpath or id. And our quest for a solution taught us something about Android.
1. Search icon (element) could not be identified using xpath or id:
Element related to the search icon could not be identified using the UIAutomatorViewer. Hence we could not write any xpath for it.
As seen in the screenshot above the ‘resource-id’ shown for the search icon is actually the id for big basket ‘checkout’ button. Sigh. BigBasket devs, you can do better!
2. Enter key event:
Next, we attempted to send an ‘ENTER’ keyevent with keycode 66(which simulates the enter key behaviour) after we input the search text but we were not successful.
text_field = self.get_element(self.search_box) text_field.send_keys(value) self.wait(3) self.driver.keyevent(66)
The Appium logs did not show any error but the event was not triggered and the search results were not shown. This blew our minds. How was a KeyEvent being ignored? Surely we were doing something wrong! We spent many an hour trying to figure out why sending the ‘Enter’ KeyEvent was failing. Finally, while pouring through Android documentation, we hit this:
You should never rely on receiving KeyEvents for any key on a soft input method. In particular, the default software keyboard will never send any key event to any application targetting Jelly Bean or later, and will only send events for some presses of the delete and return keys to applications targetting Ice Cream Sandwich or earlier. Be aware that other software input methods may never send key events regardless of the version. Consider using editor actions like IME_ACTION_DONE if you need specific interaction with the software keyboard, as it gives more visibility to the user as to how your application will react to key presses.
Sigh. Sigh. Sigh.
3. Using Co-ordinates:
So we kicked. We screamed. Tore our hair out. Banged our heads on a wall. And then went about using co-ordinates to solve this issue. These co-ordinates unfortunately vary for different devices. We perform a ‘tap_positon’ for the corresponding co-ordinates (as shown in the top right corner of the above screenshot)
text_field = self.get_element(self.search_box) text_field.send_keys(value) self.wait(3) self.tap_position([(500,840)])
And that ended our little adventure. We sincerely hope that we are missing something here. Let us know if you found a better way!
Note: We have open-sourced an intuitive, well-organized, Pythonic test automation framework. Check it out!
My journey as a tester started at Sun Microsystems (now Oracle). I was part of the testing and sustaining team for the Portal Server and Identity Management products. My first assignment was to test the Rewriter module. I enjoyed understanding the big picture, writing test cases, finding bugs and sometimes suggesting the fix too! I was hooked onto testing. Testing felt natural and intuitive to me. I am technically inclined and can write automation in Java, C++, Perl and Python. I am well versed with SilkTest, Selenium, Appium and Selendroid. I am a Computer Science graduate from BITS-Pilani. I love travelling and listening to music.