Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

How To Write a Symphony of Automation With Appium by Dan Cuellar sauce con18


Published on

In the last couple of years, Appium has added a few additional platforms to its tool belt and has become a tool of choice outside the iOS/Android “mobile apps” domain in which it rose to popularity. When it started, Appium was a tool, but it has now become a platform by which many people contribute implementation to automate many different things. Appium is becoming the language by which devices are scripted. This presents many exciting new challenges for Appium and automation developers in the years ahead. This SauceCon 2018 talk will cover a brief overview of the universe of Appium-supported platforms and devices, what the Appium development community has learned from extending Appium to support this growth, and proposed future questions as to how Appium and developers might evolve to even better accommodate supporting many more platforms and devices.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

How To Write a Symphony of Automation With Appium by Dan Cuellar sauce con18

  2. 2. ABOUT THE SPEAKER DAN CUELLAR ▸Creator of Appium ▸Experienced Software Engineering Manager ▸BS in Computer Science from Carnegie Mellon University
  3. 3. THE INCEPTION OF APPIUM INSPIRATION ▸Selenium is a great tool for automating web applications ▸There were no good tools for automating mobile applications ▸Why can’t I automate mobile applications like I automate web applications with Selenium
  4. 4. THE INCEPTION OF APPIUM LEARNINGS ▸Automation is very generalizable across multiple platforms/devices ▸Surprisingly little needed to be changed in the WebDriver protocol to support iOS and Android ▸I should have asked, “Why can’t we automate everything like I automate web applications with Selenium?” ▸Basing Appium on a widely accepted standard (WebDriver) facilitating easy adoption and the growth of the Appium user community
  5. 5. THE INCEPTION OF APPIUM WHAT’S NEXT? ▸How can we start talking about automation at a more general level such that we can use one framework to automate anything? ▸What do we stand to gain from a common automation standard? ▸How do we get device and operating system vendors on- board so that this will all work out of the box? ▸No more automation frameworks
  7. 7. AN ANALOGY MUSIC NOTATION ▸ The composer doesn’t know how to play every instrument in the orchestra, but can write for all of them ▸ The musicians control the instruments based on common notation ▸ Capabilities constrain which instruments play which parts
  8. 8. AN ANALOGY THE WEBDRIVER PROTOCOL FOR COMPOSERS ▸Instrument Capabilities ▸Name: Piano ▸Range: A1 to C8 ▸Polyphony: true ▸Pitch Bends: false ▸Sustain Control: true
  9. 9. AN ANALOGY IT GETS MORE COMPLICATED ▸A Guitar is polyphonic but… ▸Only 6 notes at a time ▸Each string can produce 1 of 25-ish notes ▸Some fingering would be impossible for a human ▸A Piano has sustain, but in several configurations ▸It can sustain only certain notes, but only in certain configurations
  10. 10. AN ANALOGY REPRESENTING COMPLEXITY ▸Capabilities as functions to cover complex states? ▸Each guitar string as its own input? ▸Each hand/foot/finger as an input to the piano?
  12. 12. GENERIC AUTOMATION QUIRKS OF APPIUM BECAUSE IT’S BASED ON WEBDRIVER For a first pass as to what abstractions need to be made, you can look at Appium’s methods and uncover it’s web-based automation base: ▸ ▸getPageSource() ▸browser
  13. 13. GENERIC AUTOMATION OBVIOUS ABSTRACTIONS ▸.click() -> .press()? ▸browser -> device ▸getPageSource -> getUIHierachy()
  14. 14. GENERIC AUTOMATION HIGHER-LEVEL ABSTRACTIONS ▸Devices have Operating Systems ▸Operating Systems have Applications, Inputs, and Outputs ▸Applications have user interfaces ▸User interfaces have elements ▸Elements are manipulated via inputs to affect outputs
  15. 15. GENERIC AUTOMATION DEVICE LEVEL ▸Device Capabilities ▸Hardware Buttons (Power, Volume Up/Down) ▸Plug / Unplug Cable
  16. 16. GENERIC AUTOMATION OPERATING SYSTEM LEVEL ▸Install Application ▸Launch Application ▸Is Application Installed ▸Set Date/Time, Language, etc. ▸Get Input / Output Interfaces
  17. 17. GENERIC AUTOMATION APPLICATION LEVEL ▸Application Settings ▸Get User Interface Hierarchy ▸Interface with User Interface Element (using associated inputs / outputs)
  18. 18. GENERIC AUTOMATION INPUTS / OUTPUTS ▸Press / Gesture at coordinates on Touch Interface ▸Get Screenshot of Graphical Interface ▸Press Mouse Button ▸Type on Keyboard ▸Speak into Microphone
  19. 19. GENERIC AUTOMATION AN EXAMPLE ▸An HP Pavilion is a device ▸The HP Pavilion has the Windows Operating System ▸Windows has the Firefox Application and a mouse, a display, and a keyboard ▸The Firefox application has a user interface (web-based interface)
  20. 20. GENERIC AUTOMATION ANOTHER EXAMPLE ▸An iPhone is a device ▸An iPhone has the iOS operating system ▸The iOS Operating System has the Spotify application, a touch input, an audio output, and a graphical output ▸Spotify has a user interface
  21. 21. GENERIC AUTOMATION EXTENSIONS ▸Bluetooth headphones are an additional output / input (if there are controls) ▸Should a wearable be represented as an additional input or output or a separate device?
  23. 23. WHY ABSTRACT? TEST LEVELS ▸Tests can be written at any / all of these levels ▸If a test is written at the application level, then in theory it could work on any operating system (provided the behavior matches) ▸If a test is written at OS level then it could be run on any device that supports that OS ▸Tests are inspectable and self-documenting
  24. 24. WHY ABSTRACT? PLUG & PLAY ▸If Device and OS vendors are onboard you can add automate new technologies without having to learn a new framework ▸You can write tests that are future-proof ▸Onus is on the application developer to provide unified paradigms and interfaces to support using multiple device categories
  25. 25. WHY ABSTRACT? CAPABILITIES ▸By capabilities can I tell where a test can run? ▸Can I add my own domain-specific capabilities to see where my tests can run ▸Capabilities at application level and operating system level, not just the device level
  26. 26. WHY ABSTRACT? APPLICATION CAPABILITIES EXAMPLE ▸App Capabilities ▸Log in ▸Send a message ▸Read a message
  27. 27. WHY ABSTRACT? IMAGINE… ▸AOL decides to release a new mobile phone operating system ▸It ships with an automation framework that has binding for generic automation ▸As a tester you can see what inputs, outputs, and applications are available ▸You can now automate
  28. 28. WHY ABSTRACT? IMAGINE… ▸I want to write a test that works across multiple devices ▸I use app-specific capabilities to expose what my app can do ▸I write automation at the application-level and it can run on many devices
  29. 29. WHY ABSTRACT? APPLICATION LEVEL AUTOMATION ▸1. Login ▸2. Compose a Message ▸3. Turn off Internet ▸4. Send Message ▸5. Verify Message in Outbox ▸6. Enable Internet Access ▸7. Verify Outbox is Empty
  31. 31. STARDRIVER EVANGELISM GAINING TRACTION ▸Build more WebDriver compatible automation frameworks ▸Add WebDriver adapters for those that don’t support it ▸KIF ▸Calabash ▸EarlGrey ▸etc. ▸Start writing an automation standard and stop writing frameworks (i.e. replace the freshly minted W3C standard)
  32. 32. STARDRIVER EVANGELISM GETTING THE WORD OUT ▸Conferences ▸Blogs ▸GitHub ▸Your Own Work