The document discusses the future of Selenium testing for mobile web and native apps. It outlines limitations of existing approaches using WebDriver and UIAutomation. It then introduces Appium as an open source test automation framework that allows controlling native and hybrid apps using the WebDriver API. Appium allows real-time interaction with apps, supports parallel testing on real devices, and can be extended to drive additional platforms like Android and desktop browsers.

1. The future of Selenium testing
for mobile web and native apps

2. Hi.
I’m JASON CARR. I work at sauce
LABS.

3. @maudineormsby

5. I’m a developer
and contributor to selenium and appium

6. Context

7. For mobile web, Web Driver

8. Selenium Grid
Selenium Grid iWebDriver.app
Script
Script
(optional)
(optional)

9. Script
Script iWebDriver.app

10. from selenium import webdriver
from selenium import webdriver
hub ==‘http://localhost:3001/wd/hub’
hub ‘http://localhost:3001/wd/hub’ iWebDriver.app
caps ==webdriver.DesiredCapabilities.IPHONE
caps webdriver.DesiredCapabilities.IPHONE
driver ==webdriver.Remote(hub, caps)
driver webdriver.Remote(hub, caps)

12. Limitations

13. iframes

14. driver.quit()

15. Alert handling

16. Javascript

17. UIAutomation

18. “…a bit like being dropped off in a
field somewhere with no map,
tools or supplies and being told
you need to build a house.”
-Alex Vollmer

19. js
js Instruments.app
Instruments.app App

20. js
js Instruments.app
Instruments.app App
client device

21. UI Automation only runs in
Instruments.app

22. Tests have to be in Javascript

23. No realtime interaction with tests

24. Hard to reuse code

25. One test at a time

26. An aside:
Android automation…

27. Monkey Runner

28. So what have we learned so far?

29. Two attempted approaches to
automation

30. Script/
Script/ App
Screen Capture
Screen Capture
Framework
Framework
client device

31. Hard to abstract

32. Very brittle

33. Hard to use with real devices

34. Hard to use with CI or parallelize

35. script
script Client library
Client library App
client device

36. Requires code modification

37. Real devices are hard

38. New framework and new tests

39. The right way to automate ios

40. Remember the testing pyramid

42. Are you writing unit tests for apps?
It’s not that hard!

43. Test your views appropriately

44. For UIWebViews use iWebDriver

45. Yes, yes, but now what?

46. Code reuse is good.

47. Realtime interaction

48. Integrate with existing automation

49. Parallel tests and real devices

50. That sounds great, but how?

51. Appium

52. Open Source
Can be extended

53. Uses webdriver API
Runs with off-the-shelf client libraries
Language agnostic

54. Real time
Interact with js interpreter or client

55. Real devices

56. Works in parallel
(architecturally)

57. No code modification

58. test script
test script
App
Appium Server
Appium Server Instruments.app
Instruments.app
client device

59. Easy to get started

60. Clone Appium

61. pip install bottle

62. python server.py /path/to/my.app

63. from selenium import webdriver
command_url = “http://localhost:4723/wd/hub”
iphone = webdriver.DesiredCapabilities.IPHONE
driver = webdriver.Remote(command_url, iphone)
fields = driver.find_elements_by_tag_name('textField’)
fields[0].send_keys(3)
fields[1].send_keys(4)
buttons = driver.find_elements_by_tag_name('button’)
buttons[0].click()

64. demo

65. Doesn’t support execute_script()
…yet. More on this later.

66. 1 Second delay between commands
UI Automation limitation

67. Still uses UIAutomation
‘Accessibility’ is important

68. where do we go from here?

69. WebKit remote debugging protocol

70. Drive mobile safari

71. Drive desktop safari

72. Drive chrome on android!

73. Android RC

74. Questions?
Thank you!

75. Resources
Appium Github Repo:
http://goo.gl/4E5F0
Dan Cuellar’s talk on Appium:
http://goo.gl/qgLha
François Reynaud on ios-driver:
http://goo.gl/pzn75
Simon Stewart’s blog on mobile testing:
http://goo.gl/8wl8j