Friday, January 13, 2012

Sencha Version 1.* and Selenium RC

A quick run down of Selenium vs. Sencha Touch Version 1.*...

I ran into quite a few issues where Selenium did not want to play nice with Sencha Touch.  Additionally, Sencha Touch only works in web kit enabled browers, so that rules out using the Selenium IDE to troubleshoot issues.

Here is a list of issues and their solutions:

Problem: How to click on a Sencha Touch button?  The built in Selenium click, click_at, etc methods would not work.

Solution: Fake out a Sencha Touch tap event by using the following steps:

  1. focus
  2. mouse_down
  3. mouse_up

Problem:  How to select a Sencha Drop Down?  The built in Selenium click, click_at, etc methods would not work AND the above "tap" method failed as well.

Solution: Fake out this event by using the fire_event method and sending the event "click" on the drop down div.

Problem: How to submit a form by emulating the "Go" button on the mobile device?

Solution:  Once again that fire_event method will work!  Send the event "submit" to the form element.   It also works to send the Native Key Press for enter, but this caused issues when running the Selenium tests.  It would only work if I manually selected the browser window while Selenium ran.  The browser had to be "on top" in order for the Native Key Press to occur.  The Native Key Press idea information can be found here.

Problem: How to find all these elements when the ids are dynamically/erratically updating?

Bad Solution:  Create extra super long xpaths until you go crazy.

Problem from Bad Solution:  The tests will not be reliable.  I noticed when I would start the xpaths at the good ol' HTML element and work my way down through the DOM, my tests were super flaky.  Nine times out of ten the test would pass, but one random time it would fail saying it could not find whatever element.  Yet nothing in the code nor test would have changed?  Even running the same test in a row a few times would cause this.  My theory is that something somewhere in the DOM is flaking out on us and therefore, causing the xpaths to be incorrect...."occasionally".

Solution: Yell, kick, and scream until unique hard-coded IDs can be used on at least some elements.  I think someone told me the Sencha people advised against using unique hard-coded IDs, which makes me wonder if their QA team does automation...   It appears that the developers don't create most of the elements themselves, they are automatically created by the Sencha Touch Framework, so all unique hard-coded IDs is not something they can do.  However, if the elements' start with tag that has a unique hard-coded ID, then the xpath can be much shorter and therefore less likely to be flaky.  For example, if the input field is composed of several divs, spans, etc all created by Sencha Touch, give that top div containing those elements a nice unique hard-coded ID.  Then the xpath could be shorted to something like "//div[@id='unique-never-change-me-please']/div[2]/span".


Me:  QA Engineer, typically tasked with manual testing but itching to do automation/development

The project:  A mobile web application built using the Sencha Touch framework

The blog:  lessons learned, tips, tricks, etc

I hope this will be a good resource for other people trying to automate tests in Selenium for the Sencha Touch framework.  I started testing a mobile web application created using the original Sencha Touch release and Selenium in Python.  Currently, I've been testing a re-implementation of this project using a newer Sencha Touch release and Selenium in the Robot Framework.