{"id":153,"date":"2013-03-06T23:06:36","date_gmt":"2013-03-06T23:06:36","guid":{"rendered":"http:\/\/blog.mozilla.org\/webqa\/?p=153"},"modified":"2013-03-06T23:06:36","modified_gmt":"2013-03-06T23:06:36","slug":"part-3-ui-testing-on-firefox-os-apps-coded-differently","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/fxtesteng\/2013\/03\/06\/part-3-ui-testing-on-firefox-os-apps-coded-differently\/","title":{"rendered":"Part 3: UI Testing on Firefox OS. Apps are coded differently"},"content":{"rendered":"<p>By Zac Campbell<\/p>\n<p>While a Firefox OS app is HTML, CSS and JavaScript we are all familiar with there are some significant design differences. These design differences are necessary because users have different expectations depending upon the device they\u2019re using, be it mobile, desktop or otherwise.<\/p>\n<p>Mobile phone users don\u2019t have the patience to click and wait for a page to load. The less powerful phone CPU combined with unreliable cell network internet means waiting for pages to load is a very poor user experience.<\/p>\n<p>Finally, we have a tiny screen to work with so app developers can\u2019t show large volumes of data at once. We either have to switch pages or pan to reach the off-screen content.<\/p>\n<p>Mozilla developers have built Firefox OS apps with this in mind. The main design difference of a well-written Firefox OS app is that the content of the app is generated as one single HTML page when the app is loaded and then switched on and off using JavaScript and CSS when the user demands it. This keeps the user experience feeling fast!<br \/>\n<a href=\"http:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram1.jpg\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-158\" alt=\"blog-diagram1\" src=\"http:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram1.jpg\" width=\"669\" height=\"409\" srcset=\"https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram1.jpg 669w, https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram1-300x183.jpg 300w, https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram1-600x367.jpg 600w\" sizes=\"(max-width: 669px) 100vw, 669px\" \/><\/a><br \/>\nThis diagram depicts the Firefox OS Music app if we were able to see it as one big webpage. The blue box represents the viewport of the smartphone. Each display panel is a &lt;div&gt;. The list, sublist and player &lt;div&gt; are all loaded in one HTML page and scrolled in and out of the phone\u2019s viewport using CSS3 <a title=\"Transform\" href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/CSS\/transform\" target=\"_blank\">transformX<\/a>. The CSS3 <a title=\"transition\" href=\"https:\/\/developer.mozilla.org\/en-US\/docs\/CSS\/transition\" target=\"_blank\">transition<\/a> attribute animates each of these transitions so it looks smooth.<\/p>\n<p>How does this affect UI testing on Firefox OS? The main problem is that we are missing are the page loading events. WebDriver is very good at detecting these events and automatically pausing itself while loading a new page. When testing the Music app on Firefox OS we\u2019re not loading a new page so there is no clear delineation of the page load starting or ending. Instead, we need to be very precise in telling Marionette to wait for the CSS transition to complete before we can continue the test.<br \/>\n<a href=\"http:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram2.jpg\"><img decoding=\"async\" loading=\"lazy\" class=\"alignnone size-full wp-image-159\" alt=\"blog-diagram2\" src=\"http:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram2.jpg\" width=\"669\" height=\"409\" srcset=\"https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram2.jpg 669w, https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram2-300x183.jpg 300w, https:\/\/blog.mozilla.org\/fxtesteng\/files\/2013\/03\/blog-diagram2-600x367.jpg 600w\" sizes=\"(max-width: 669px) 100vw, 669px\" \/><\/a><\/p>\n<p>In this example of the Music app, when we change into the list mode view the &lt;body&gt; tag of the app is set with the CSS tag \u201clist-mode\u201d which shifts the body -100%. Waiting for an element that matches the CSS locator \u201cbody.list-mode\u201d to be visible on the page is how we know the content we need is on screen and the test is ready to continue.<\/p>\n<p>Here is a Python code snippet for waiting for an element to be displayed:<\/p>\n<pre>def wait_for_element_displayed(self, by, locator, timeout=30):\n    timeout = float(timeout) + time.time()\n\n    while time.time() &lt; timeout:\n        time.sleep(0.5)\n    try:\n        if self.marionette.find_element(by, locator).is_displayed():\n            break\n    except NoSuchElementException:\n        pass\n    else:\n        raise TimeoutException('Element %s not visible before timeout' % locator)<\/pre>\n<p>Which is called (with the example\u2019s locator) like this:<br \/>\n<code><br \/>\nwait_for_element_displayed(\u2018css selector\u2019, \u2018body.list-mode\u2019)<br \/>\n<\/code><\/p>\n<p>Another thing you may need to be careful of is the checking of HTML elements. As the App is one large web page there are many many more HTML elements on the page than are visible in the viewport. For interactions like click and tap Marionette will check the visibility of the element before allowing the interaction to take place. However when checking attributes of elements you need to be sure that you are checking the correct element. You could easily be checking an element that\u2019s outside the viewport and irrelevant and in the worst case produce a false positive. Avoiding this is a matter of carefully crafting locators and waits and cross-checking your work before committing running your test.<\/p>\n<p>This example of design for the Music app is not the same for all Firefox OS apps and I intend it to only serve as an example of what to look out for. Be prepared to be up against lots of CSS3, JavaScript and a single but very dynamic web page!<\/p>\n","protected":false},"excerpt":{"rendered":"<p>By Zac Campbell While a Firefox OS app is HTML, CSS and JavaScript we are all familiar with there are some significant design differences. These design differences are necessary because &hellip; <a class=\"go\" href=\"https:\/\/blog.mozilla.org\/fxtesteng\/2013\/03\/06\/part-3-ui-testing-on-firefox-os-apps-coded-differently\/\">Read more<\/a><\/p>\n","protected":false},"author":1359,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[24660],"tags":[8630,4261,24660,27793],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/posts\/153"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/users\/1359"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/comments?post=153"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/posts\/153\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/media?parent=153"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/categories?post=153"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/fxtesteng\/wp-json\/wp\/v2\/tags?post=153"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}