Embed Size (px)
Citation preview
Automate your Appium tests like a pro
Wednesday, April 27th
AboutQualiTest
QA and testing isall that we do!
World’s 2ndlargest pure play
TestingCompany
Over 2,700 testingprofessionalsworld wide
Business Assurance
QA &TestingFocus
ResultsBasedTesting(RBT)
Contractual guarantees forquality improvement &
cost reduction
ManagedTesting
Solutions(MTS)
Long term, SLA-based testingoutsourcing
Industry & Technology Expert
2
GlobalServiceDeliveryModel
Onshore, Near-Shore,Offshore and Crowd
Testing
What is Appium?
| Android and iOS Devices Automation Toolkit
| Provides real device control on Native, Mobile Web and Hybrid apps
| Based on the hugely successful Selenium WebDriver technologies
3
What are the benefits to Appium?
|Object-based recognition, more resilient to minor GUI changes than image-based
|No side-loaded software or libraries on the device
|Widely supported, time-tested foundations| Part of the WebDriver family of technologies
| Many of the concepts and approaches are already known to experienced WebDriver engineers
|Open-source project, minimal cost
4
What are the disadvantages to Appium?
| Limited avenues for commercial or SLA support
| Code-heavy solutions
| Limited to Android and iOS testing
5
How does Appium work?
| A lightweight, NodeJS server sits alongside mobile-vendor provided SDK
| For Android we leverage Google’s own Android Developer Tools
| For iOS we leverage Apple’s iOS SDK
| The server is listening for traffic coming in using WebDriver’s JSON wire protocol
| When traffic comes in, it passes through to a connected device using the SDK
6
How Does Appium Work?
Appium Host Test Automation Suite
iOS/Android Device NodeJS ServerAndroid/iOS SDK RemoteWebDriverImplementation
Automation Scripts (Java, C#, Ruby, etc.)
JSON Wire Protocol
Can be same machine or separate
7
How do we write Appium tests?
| Because Appium listens via neutral protocols, test developers can choose from a variety of languages to use.| Appium project provides language
bindings for Java, C#, Ruby, PHP, Python and JavaScript
| Developers can write their own bindings
8
Knowing what to look for
| Traditional WebDriver tests use HTML structure details to interact with the page
| iOS and Android GUI elements can be located using identifiers, Xpath expressions and text just like web page elements
| We find these using mobile tools in Appium and SDKs rather than a browser
9
10
So what does this mean?
|A standard app development environment is easily adapted to an Appium test environment
|We can take a lot of WebDriver’s principles and apply them to mobile testing
|Appium tests look and feel very like WebDriver web tests; but we point to a device not a browser.
|We can re-use lessons learnt, frameworks and best practices from WebDriver testing in Appium.
11
Appium Test Best Practices
|De-couple test fixtures from test logic
|LoginPageObject.java
| Use page object patterns to keep tests resilient to application changes
12
Appium Test Best Practices
|Test Scripts should be high-level |LoginTests.java
| Test Scripts document a Journey through a system
| Scripts call lower level functionality at business and page layers to drive interaction
| Use Data-Driven techniques to create scalable tests
13
Appium Test Best Practices
| Invest in automation infrastructure| The faster and more regularly we run
automated tests, the faster they find problems, the faster we drive up quality
| Dedicated environments and software build phases are instrumental to this
14
Appium Test Best Practices
|Automate from the bottom up| Appium tests are integration tests, covering
more functionality than unit tests, but are harder to set up and slower to run. If unit test coverage is high, we need less of them
| If unit test coverage is low, integration test failures become less-efficient at pinpointing defect areas
15
Appium Test Best Practices
| Empower test developers| They should be provisioned with all they need
to run tests locally, instead of leaning on shared build- servers and environments to identify failure
| The software build should be chained not to run integration tests if unit tests failed
| There’s no point in running slow tests when fast tests already told us there’s a defect
| Test your tests!
16
About the Demo: giffgaff
| giffgaff are a mobile telephone network based in the UK
| Founded in 2009 with a vision to disrupt the market
| Built around their core values of being lean, disruptive and driven by their members
| giffgaff is ’run by you’ with hundreds of implemented ideas generated by the ’community’
17
About the Demo: giffgaff
| Some of the functionalities of the app include allowing users to:
| View their balance| Topup their phones
| Talk on the community
| Change their account settings
18
About the Demo: The Tests
| The test cases implemented for this demonstration cover the following scenarios:
| Able to successfully log in and out as a giffgaff member
| Unable to log in with an invalid password
19
About TestObject
Mobile Automated
Testing
Open sourceTesting
Frameworks
MobileManual Testing
2 Offices in Germany
App TestingSpecialists
Our Clients
200+Satisfied
Customers
20
Typical Appium Test Script
21
Typical Appium Test Script
| Not using abstraction to our advantage: low level and high level mixed together;
| Low readability;
| Low maintainability: bad news if you have a new release every two weeks.
22
The PageObject Pattern
| The goal:| Enhancing test maintainability by increasing
readability and reducing code duplication.
| How to achieve it:| Every* page in a website / every* screen in an
app is represented by a class;| Every PageObject encapsulates the
interactions the user can have on said page/screen, hiding the underlying widgetry.
23
The PageObject Pattern
24
The PageObject Pattern
| If we have this in place…| tests become more readable (as you will see in
a moment – they will read as a sequence of user interactions on a screen) and high-level;
| if the UI changes for the page, all changes to support that new UI are located in one place (the PageObject class for that page).
25
Questions and Answers
