We develop almost identical apps for both Android and iOS. Maintaining separate test suites becomes an overhead over a period of time as the test suites begin to grow. We hare now gradually moving our test infrastructure to Appium so that we can have a single test repo which is easy to maintain.
This document summarizes an Appium webinar presented by Jonathan Lipps on April 24, 2018. It discusses updates to Appium 1.8 including support for the W3C WebDriver spec, app management features, improved screen handling, clipboard support, auxiliary app support, iOS screen recording, iOS performance monitoring, Android log streaming, and Android instant app support. It also covers tips for element locators, using deep links to speed up tests, testing app upgrades, and cross-platform testing best practices.
This document provides information about Appium, an open source test automation framework for use with native, hybrid and mobile web apps. It discusses Appium's architecture and features, how to set up Appium for testing iOS and Android apps, different language clients available and requirements for writing tests in Java. The document also covers new capabilities and strategies introduced in Appium, such as TouchActions and MultiTouchActions.
Using Selenium to Test Native Apps (Wait, you can do that?)Sauce Labs
This document discusses automating tests for native mobile applications. It begins by describing the challenges of testing iOS applications using Apple's UI Automation and Instruments tools. It then reviews two attempted approaches for automation that were brittle and difficult to use at scale. The document advocates for using Appium, an open source test automation tool that allows controlling native and hybrid applications using the WebDriver protocol. It provides an example of using Appium to automate tests for a native iOS application and discusses the tool's benefits and limitations. In closing, it outlines opportunities to further enhance Appium's capabilities and integrations.
This document summarizes Appium's plans to improve mobile automation testing capabilities. It discusses [1] enhancing element inspectors for iOS and Android, [2] improving test speed through techniques like parallelization and Dockerization, [3] handling tests across multiple simulators, [4] adding support for new platforms like wearables and TVs, [5] developing an "enterprise" version, and [6] creating new "*Drivers" to expand automation to other domains beyond mobile. The goal is for Appium to become a standard interface for automating any platform or device through the use of specialized driver wrappers.
"Learn All Aspects Of Appium step by step, Enhance your skills & Launch Your Career, On-Demand Course affordable price & classes on virtually every topic.Try Before You Buy
for maven online training visit: https://goo.gl/YKsHBZ"
[Srijan Wednesday Webinar] Mastering Mobile Test Automation with AppiumSrijan Technologies
Speaker: Justin Ison
Check out the complete session slides here: http://www.srijan.net/webinar/mobile-...
This session dives into the history of Appium, and it's pros and cons. The speaker also looks at how to write a good test setup and collect meaningful data points. We look at quick demos and comparisons of how Appium significantly reduces test times.
And you definitely should hang around till the Q&A session, where participants pitch in with their issues and queries. The speaker answers all the questions, sharing additional information and tips on Appium.
Developed by Sauce Labs and a thriving community of open source contributors, Appium is a cross-platform automation framework for testing mobile web, native, and hybrid applications.
In this webinar, hear the latest about Appium version 1.3.x from project lead Jonathan Lipps as he takes us on a tour of the stability improvements and features the team has added since the Appium 1.0 release back in May of 2014.
Mobile automation testing with selenium and appiumBugRaptors
Appium runs on real devices and emulators. It takes the Selenium commands from your test code and translates them into a readable format for UI Automator, using the WebDriver JSON Wire Protocol. The UI Automator testing framework lets you test your user interface (UI) efficiently by creating automated functional and UI test cases that can be run against your app on one or more devices.
Appium is an open-source tool for automating native, mobile web, and hybrid applications on iOS mobile, Android mobile, and Windows desktop platforms. Native apps are those written using iOS, Android, or Windows SDKs. Mobile web apps are web apps accessed using a mobile browser (Appium supports Safari on iOS and Chrome or the built-in 'Browser' app on Android). Hybrid apps have a wrapper around a "webview" -- a native control that enables interaction with web content. Projects like Apache Cordova or Phonegap make it easy to build apps using web technologies that are then bundled into a native wrapper, creating a hybrid app.
Importantly, Appium is "cross-platform": it allows you to write tests against multiple platforms (iOS, Android, Windows), using the same API. This enables code reuse between iOS, Android, and Windows testsuites.
Android UI Testing with Appium
This presentation covers:
- how appium works
- setting up test development environment with AndroidStudio
- running tests
- UI automation best practices
- common problems with automation
Appium is a tool for automating native and hybrid mobile apps. This document discusses how to set up an Appium project to test Android apps. It covers installing Appium and related tools on Windows, setting desired capabilities, locating elements, performing actions, validating results, and running tests. The goal is to create an IntelliJ project that uses Appium to test a sample Android app by interacting with app elements and verifying the app's behavior.
Sitam Jana presents on mobile automation. The document discusses challenges in mobile testing like compatibility and regression testing. It then covers mobile automation tools like Appium, Robotium and MonkeyRunner that can automate testing on Android and iOS. The last sections provide steps to set up the environment and demonstrate MonkeyRunner through sample code and configuration in Eclipse.
This document discusses Android and iOS automation using Appium. It provides an overview of Appium, including that it is an open source test automation tool for mobile apps that supports automation of native, hybrid and mobile web apps. It also outlines the features of Appium, how to set up automation for Android and iOS apps, and demonstrates automating a mobile web app.
Testing Your Android and iOS Apps with Appium in Testdroid CloudBitbar
Testdroid Cloud is now fully supported with Appium, an open source test automation framework for use with native and hybrid mobile apps.
This slide deck was used on the presentation at Appium Meetup by Jouko Kaasila, Co-founder and COO at Bitbar. You will get an overview of how you can leverage Appium in your mobile app testing within Testdroid Cloud.
Stay tuned and join our upcoming webinars at http://bitbar.com/testing/webinars/
Appium is one popular open source automation tool. Used for automating native, mobile web, and hybrid applications on iOS and Android platforms. It uses WebDriver JSON wire protocol to drive the iOS apps. Appium server is written on node.js and talks to iOS using UIAutomation Instruments.
Mastering the Art of Mobile Testing by Akshita PuramQA or the Highway
The document discusses mastering the art of mobile testing. It outlines three key mindset shifts for mobile testing: (1) anyone can create automated mobile tests, (2) mobile web technologies will overtake native apps, and (3) mobile testing must target both the UI and API layers. It also discusses features that a robust test automation framework should include, such as object recognition, different test creation techniques, cross-platform execution, and reporting. Finally, it lists some popular mobile testing tool vendors that cover functional automation, performance testing, and device management.
This document discusses cross-platform mobile development. It defines cross-platform development as developing applications that can run on multiple platforms simultaneously. The document then explores different cross-platform approaches like web apps, hybrid apps, interpreted apps, cross-compiled apps, and generated apps. It provides details on how each approach works and when they are involved in the development process. The document also compares the different approaches based on factors like native access, performance, cost, and tools. It concludes that cross-platform options are not fully mature but can be good choices for prototypes, existing web apps, or as a shortcut to the market.
Thick and Thin Lines in Choosing Mobile Test Cloud Environment by Shrinathach...Agile Testing Alliance
Shrinathacharya has given a session on Thick and Thin Lines in Choosing Mobile Test Cloud Environment in ATA Bangalore 13th Meetup. All copyright belongs to the author.
The document discusses test strategy considerations for mobile applications. It notes that mobile device usage is growing rapidly and surpassing other technologies. A test strategy outlines the testing approach and covers scope, roles, environment, tools, risks, schedule, and priorities. Testing mobile applications presents unique challenges related to the environment, application behaviors across devices, users, different devices and form factors, networks, and automation. The document recommends various strategies for testing mobile apps including using physical devices, simulators, cloud-based testing services, crowdsourcing, and test automation tools specific to Android and iOS. It also covers different types of mobile testing like usability, performance, security, and compatibility testing.
Enough is not enough - Test Strategy for MobilevodQA
The document discusses test strategy for mobile applications. It outlines some key aspects of a test strategy such as scope, roles and responsibilities, environment, testing tools, risks and mitigation, and schedule. It then discusses the growth of mobile usage and some big challenges in testing mobile apps such as different environments, applications, users, devices, networks, and automation. The document provides an overview of different types of mobile apps, testing approaches like using physical devices, simulators, cloud testing, crowdsourcing, and automation tools for both Android and iOS platforms. It also covers various types of testing like usability, performance, security, and compatibility testing that are important for mobile.
The document discusses test strategy considerations for mobile applications. It outlines key challenges in mobile testing like frequent OS changes, different device types and form factors, network interruptions, and automation challenges. It then covers various mobile testing approaches like using physical devices, simulators, cloud-based testing, crowdsourcing, and automation tools for both Android and iOS. The document also lists different types of mobile testing like usability, performance, security, and compatibility testing.
No matter how many devices, platforms or screen-sizes you test your mobile app on, your testing may still not be enough. In this era of ever increasing mobile devices and varied platforms, this is bound to happen unless you have a test plan tailored for the mobile world. The intent of this talk is to brace ourselves for this challenge and envision a test strategy for mobile that covers these widespread avenues.
The document discusses best practices and challenges for mobile application testing. It covers differences between mobile and traditional web testing such as integration, interruption, and gesture testing. Challenges include the variety of devices, simulating real life scenarios, usability, automation, and performance testing. Guidelines provided include determining a test matrix based on factors like market share and risk, setting up a mobile lab with different devices, and choosing automated or manual testing methods.
Learnings from Mobile Application TestingThoughtworks
This document provides an overview of mobile app testing challenges and best practices. It discusses the different types of mobile apps (native, mobile web, and hybrid), as well as challenges related to the large number of devices and OS versions, simulating real-life scenarios, usability, and development practices. Automation testing tools are presented, along with the importance of selecting representative devices for testing, simulating real-life scenarios, monitoring device logs, and using automation selectively on devices and simulators. The document concludes by offering ThoughtWorks' mobile app testing services.
The document discusses native mobile apps versus hybrid mobile apps. It provides an overview of advantages and disadvantages of each approach. Native apps provide better user experience but require separate development for each platform. Hybrid apps allow cross-platform development but can have performance issues. It also examines case studies of how LinkedIn, Facebook, and Dropbox developed their mobile strategies using both native and hybrid approaches.
The document provides information on Neev Mobile Offerings including their expertise in mobile technologies like Android and iOS. It discusses Neev's competencies in mobile development, UI/UX design, and testing. It also includes case studies on mobile apps developed for various domains like travel, retail, gaming etc. and case studies on SDK development. It compares native and hybrid app development and provides details on PhoneGap/Cordova for building cross-platform mobile apps.
The document discusses mobility and application development trends. It notes that developers value reach across platforms most and making money second. Many developers earn less than $500 per app monthly. HTML allows access to larger desktop and mobile audiences with more potential to earn over $500 monthly. Going forward, tools that support multiple platforms and allow reuse of existing skills will be most popular. Native apps have most access to device features while web apps have broadest reach but less engagement. The document recommends Microsoft tools like Xamarin for porting existing .NET apps or targeting Windows platforms to reach larger audiences.
Get Mobile | Mobile & Digital Marketing | Crystal Olig | Upward | OxiemLessing-Flynn
Why marketers should care about mobile marketing now. Includes statistics on mobile device proliferation, responsive website design, mobile websites vs. mobile apps, and how the market will continue to change.
Presentation given at Interact13 conference in January 2013, Springfield Ohio.
The document discusses mobility and application ecosystems today and what the future may hold. It summarizes findings from a developer economics study that show most developers value platform reach and revenue opportunities. Many developers currently earn less than $500 per app monthly. The document also examines cross-platform development tools and frameworks, comparing their technologies, languages, and developer satisfaction ratings. Key criteria for evaluating native, hybrid, and web apps are outlined. The document concludes by discussing opportunities for Windows development and encouraging developers to learn HTML5, target multiple device types and platforms, and contact Microsoft with ideas.
The document discusses the importance of having a native mobile strategy. It notes that 86% of time spent on mobile is in native apps, not browsers, and users want native apps for services they use often. Native apps provide better performance through hardware acceleration and features like gestures that enhance the user experience. Focusing on quality is important, as high quality brings user re-engagement. The document recommends building native apps to deliver high quality, value-adding experiences for users and exploring new technologies like Swift 2.0 that make app development more approachable.
Introduction to the course
Hybrid mobile development frameworks
Mobile thinking
This presentation has been developed in the context of the Mobile Applications Development course, DISIM, University of L'Aquila (Italy), Spring 2016.
http://www.ivanomalavolta.com
This document provides an overview and agenda for a presentation on practical mobile app testing. It discusses trends in mobile devices and platforms, differences between mobile web and apps, platforms for mobile development, challenges in mobile app testing, and strategies and best practices for testing. It also presents a case study of a mobile app called "SOS! Sick Bird" that helps users in Hong Kong locate nearby government clinics.
Tina Su discusses how Intuit implemented continuous integration and mobile test automation to speed up their mobile development cycle. They created an Intuit Virtual Device Lab (VDL) that gives developers browser-based access to real mobile devices. This allows automated tests to be run simultaneously across many device configurations. Intuit also developed a shared test library and uses Cucumber and Calabash for behavior-driven testing on Android and iOS. Continuous integration with the VDL and test automation reduced Intuit's iteration cycle from days to minutes, improving release quality and developer productivity.
Tina Su discusses how Intuit implemented continuous integration and mobile test automation to speed up their mobile development cycle. They created an Intuit Virtual Device Lab (VDL) that gives developers browser-based access to real mobile devices. This allows automated tests to be run simultaneously across many device configurations. Intuit also developed a shared test library and uses Cucumber and Calabash for behavior-driven testing on Android and iOS. Continuous integration with the VDL and test automation reduced Intuit's iteration cycle from days to minutes, improving release quality and developer productivity.
Speed and quality through Mobile Continuous Integration on Real Devices at Intuit. The presentation share about our key considerations for 3rd-party vs custom built solutions and how we created Virtual Device Lab and test automation framework to enable end-2-end Mobile continuous integration that reduce development iteration cycle from Days to Minutes
Similar to Cross platform test automation using Appium (20)
24. Appium Architecture
WebDriver
Scripts
1. Commands are
sent in form of JSON
via HTTP
2. Appium server invokes
platform specific tools to
execute commands
3. Client sends back
response to the
Appium server
4. Appium server
logs the result
32. Test Stack (now)
iOS Android
Native
Team City
Appium, Cucumber, Rspec
Objective C / Swift Java / Groovy
UIAutomation,
Bwoken
Robotium
Kiwi, KIF RoboSpock
33. Appium Limitations
• 1 iOS test per Mac OS – instruments
limitation
• Limited support for Android < 4.1
• Some gestures not supported
• Windows Mobile not supported
• Image comparison not supported
34. The road ahead
• Migrate tests to Appium
• Review existing tests
• Use real devices
Good evening all
Before I begin I would like to thank Ady, Vikas and everyone else involved in organising the meetup. You guys are doing a brilliant job.
About me – I work as a QA lead for the mobile team at MYOB since last 1 year and was on their flagship windows product prior to that.
Before joining MYOB I was working with TW
Having worked for these companies has given me opportunities to work on a variety of platforms and tech stacks but I sincerely believe there is still heaps to learn
I love travelling and exploring new places.
So that was a bit about me, now I would like to know a bit about you all.
Who here has worked on mobile project
Have you used some sort of automation tool
Great, so we do have a good mix here – people who have worked on some of these areas and some who are keen to learn more
So what’s the big deal about mobile
A recent survey by Gartner indicates that by 2018 more than 50% of the users will use a mobile device first in order to access the internet.
Well I would say mobile is not the future anymore in fact it is the present now.
Another study by Morgan Stanley suggests that early last year the number of mobile users have already surpassed the total number of desktop users globally.
Therefore, as a result - a lot of companies and products are now moving to the mobile first strategy.
They want to make sure whatever you are able to do on their web site you should be able to do on your mobile too.
I don’t remember when was the last time I logged in to facebook on my laptop, neither have I logged in to my bank’s website for quite some time
SO far I have used the word “apps” quite a few times. Now let us understand what does an app mean?
Primarily there are 3 kinds of mobile apps – Native, Web and Hybrid
Native - A native app is an app developed specifically for the targeted phones operating system, for example iOS or Android.
The user experience, interaction with the phones technology & performance of these apps is unrivaled. There is a considerable dev and testing effort involved because you are dealing with 2 entirely different codebases. Key words you may hear when explaining the development environment are Objective-C, Swift, Java. This app is available in the app store.
Responsive – Mobile web or often referred to as responsive is nothing but a web page that renders to a wide range of devices. Imagine opening Google or yahoo on your phone’s browser and you will notice that despite so much of content and such small screen of your mobile the content doesn’t get distorted. So these are not available on app store and rather you simply open them on your browser.
Hybrid - A hybrid app is a mix between web and native. Technologies such as Phonegap and Cordova or Titanium allows developers to take web technology and wrap it in a native shell. This is done so the app can take advantage of the phones hardware and features but can also be ported across platform. These are again downloadable from the app store so from a normal user’s perspective they don’t see much of a difference.
Talking about our apps – we have 2 apps – PayDirect and OnTheGo which are available for both android and iOS
These are all native apps. So technically there are 4 apps to be taken care of.
PayDirect allows our customers to pair the card reader via bluetooth and then take credit card payments. They can swipe, insert or tap the card in order to do so.
OnTheGo is primarily meant for raising invoices. Its being used by a lot of tradees or small businesses who have to visit different places.
So imagine a plumber coming to your place who aftre doing his job can straight away raise an invoice and get his money right then. Its gaining a lot of traction in our small and medium enterprise business division.
Apart from creating invoices, you can also create contacts or get in touch with our customer care.
There is a but of feature overlap in these invoices.
We are still adding more features and typically do a release every 2 weeks. So you can imagine we always have to be on our toes.
15% of SME businesses are using these apps now and growing 10% compounded monthly
Big challenges on small devices. Mobile apps pose new challenges to testing:
Rating and Reviews. Bad quality may cause trouble to the reputation of the company and brand. In the era of millions of charts, lists and reviews there hasn’t been a case when a company released a low-quality app and people didin’t find out about it. The influence of bad reviews can be drastic.
Device and OS distribution. Mobile devices change and improve with unprecedented speed. Annually hundreds on new devices appear on the market. Different screen sizes, form-factors and the variety of OS often cause problems to apps.
Urgency. You need to be fast, extremely fast to move with the times. Teams should create design, write code, test and release an application within a very short period of time. Traditional manual testing doesn’t meet the speed requirements of mobile world.
Complexity. All the mobile devices are becoming more and more elaborate, and are based on more and more advanced technologies. Location recognition, Wi-Fi, real-time events, popups – all this makes both manual and automated testing way more complicated.
I would say automation could be considered both challenge and a solution for all these other challenges.
Because the time to market is so short you cant really rely on manually testing all the flows in the app when doing a release.
So its best to automate your test cases. But please while doing so be congnizant of the basics such as testing pyramid.
There are a plenty of automation tools available in market. I have put a few of those here on this slide.
Some of these are platform specific whereas others support cross platform automation.
Robotium is an Android test automation framework that fully supports native and hybrid applications. Robotium makes it easy to write powerful and robust automatic black-box UI tests for Android applications. With the support of Robotium, test case developers can write function, system and user acceptance test scenarios, spanning multiple Android activities.
UIautomator, by Google, provides an efficient way to test UIs. It creates automated functional test cases that can be executed against apps on real Android devices and emulators. It includes a viewer, which is a GUI tool to scan and analyze the UI components of an Android app.
Espresso, by Google, is a pretty new test automation framework that got open-sourced just last year, making it available for developers and testers to hammer out their UIs. Espresso has an API that is small, predictable, easy to learn and built on top of the Android instrumentation framework. You can quickly write concise and reliable Android UI tests with it.
Calabash is a cross-platform test automation framework for Android and iOS native and hybrid applications. Calabash’s easy-to-understand syntax enables even non-technical people to create and execute automated acceptance tests for apps on both of these mobile platforms.
Not very long ago our test stack used to look something like this.
For iOS we were using UIAutomation for test automation.
For android were had all our tests automated using Robotium
We were also using Kiwi and KIF for Unit and Integration testing in iOS
For Android unit testing we use Robospock
Apart from the apps we also have a server component which handles most of the business logic. The server is ruby code base and we use cucumber for automating server acceptance tests
So even though from business perspective these are more or less identical apps, we were compelled to maintain 2 entirely different test suites.
So we knew there was scope of improvement and we started jotting down what were the things we were looking for
First and foremost we wanted to use a cross platform automation tool that could allow us to run the same test against both android and ios.
This will mean Reusable Code And Less maintenance effort
While as of now all our apps are native, our tech roadmap is quite diverse and there is a potential that we may create hyrbrid or web apps in future. So wanted to take our tech roadmap into consideration and invest in a tool that could automate these other types as well.
As new devices and operating system versions are released every day we want to go for a tool which is up to date with all these developments. And also the one which could allow to increase our coverage as and when required.
As a next step to scalability we wanted to look for a tool which is compatible with a cloud based testing service provider.
There are cloud based testing service providers that allow you to run your tests on an array of devices and operating systems and then generate a detailed report.
So far we have had our test written in tools which only supported a specific scripting language. Which means if a test fails or there is any issue only the people who have worked on that language will be able to investigate. We wanted a tool that could allow us to chose a language of our choice.
We definitely wanted to add BDD layer to our tests. So that these tests could be written even by the non technical stake holders of the project such as product owner.
Also the BDD tests act as a living documentation.
Keeping all those motivations in mind, we started looking for cross platform automation tools and narrowed down to these.
MonketTalk lost early in the race because of various reasons. In fact it has been acquired by Orcale recently so its future remains uncertain.
Calabash is definitely good and I would say as popular as Appium
The github stats vary slightly.
However, Appium’s USP is that it doesn’t require you to alter the app because the appium server utilizes the platform specific tools in order to gain control of your device. I will talk about its architecture in a bit more detail soon.
Calabash is undergoing a revamp and will come up as 2.0 wherein they are re-writing the API from scratch so there could be some major changes coming up
So why did we chose appium
Supports both Android and iOS
Because it takes advantage of selenium’s json wire protocol, all the languages that can be used to write selenium tests can be used to write appium tests too.
Supports native, web and hybrid
It allows you to run your tests in an emulator or on a real device
Being selenium based, it follows a well formulated API so if you have ever worked on selenium before, picking up Appium becomes quite easy.
Appium uses 2 technologies: the Selenium API (that is, a subset of Selenium commands that are relevant for mobile testing), and the WebDriver JSON Wire Protocol. The Selenium/WebDriver combo is a de-facto standard in end-to-end system testing and is well-known to many developers and testers.
Appium is sponsored by Saucelabs and therefore it seemlessly integrates with their cloud offering. However, it is compatible with most of the other players in the market.
It does support BDD which was another key motivation for us.
There is a strong community support. They have their own discussion forum and even the issues raised on github get responded to pretty quickly.
As I said before, it allows you to Test the same app that you would submit to app store – you do not need to compile a third party framework into your app’s code that needs to be stripped out later. Avoids the risk of introducing any unforeseen bugs. Test the same app as you would release.
And last but not the least, it is open source so its free and you can fork and create your own version if you want.
So how does Appium do all this? Let’s try to understand what happens behind the scenes.
Appium basically is an HTTP server written using nodeJS that exposes a REST API
Provides common front end API to the totally different back ends
It is almost the same as the Selenium server that gets HTTP requests from Selenium client libraries.
Step 1 – commands are sent in form of JSON via HTTP
Step 2 – Appium invokes platform specific tools to execute the commands
Step 3 – Client sends back response to the appium server
Which is then logged on the console
When I say platform specific Appium uses UIAutomator which is capable of controlling the entire device on Android and execute these commands
Similarly, for iOS it uses Instruments which is again provided by apple and is capable of controlling and executing commands on an ios device
At the webscripts level, it uses desiredcapabilities the same way you can do it for dowing cross browser automation with selenium.
Appart from running the appium server from the command line, you can also launch it via UI.
The Appium app is capable of doing pretty much everything that you may want to do with command line, so you don’t need to worry about Node.
Clicking on the search icon here takes you to the appium inspector
The inspector enables you to check out the hierarchy of your app.
This can come in handy when writing tests.
equivalent of selenium IDE
Also supports basic record and playback
We also added a BDD layer to our appium tests, in order to do this we were using cucumber to write scenarios
The step definitions were written using Ruby
And we are following page object pattern.
The Page Object pattern represents the screens of your app as a series of objects. You can separate out your testing code from the app screens. It also provides you the ability to reuse a screen in multiple tests. So if there is a UI change required, you don’t need to modify all the tests rather just update the page (screen)
Here is a small example of a test scenario written using cucumber
All I am trying to do here is
Launch the app
Login using valid credentials
Once I successfully login, I should be taken to the setup passcode screen
Here is the step definition for this scenario written in ruby
As you can see we have tried to write minimal code here and rather are calling our screens whenever we want to do a particular operation on those screens
Here is how a sample screen would look like
They are both inheriting a common base class
They are a few differences in these screens
The title for Android screen is MYOB where as for iOS it is login
Similarly, we are using IDs for android and name for iOS
It’s a good idea to keep pages separate for both the platforms so that change in one app doesn’t impact the tests for the other platform
Now I thought because login is such a quick scenario it will hardly take a few seconds to execute and so I have chosen a slightly longer feature for the purpose of demo
So in this example here I am testing the dashboard feature
GO TO NEXT SLIDE
=======================
So as you can see as part of these scenarios I drill into various areas of the app and assert that I am actually there
GO TO DEMO
So after all these recent changes, our test stack has grown up a bit.
We have this another layer of acceptance tests written using Appium and Cucumber
Appium is No silver bullet. There are some limitations.
For example – you can only run 1 iOS test at a time. This is also because of the fact that Appium uses apple’s instruments framework under the hood and you can have only one instance of instruments running at a time. For android you need to start multiple appium servers with different flags
It has limited support for Android versions lower than 4.1. There is a work around available by using Selendroid.
Appium extends the WebDriver spec with extra commands to support mobile gestures such as long tap and shake. However, not all mobile gestures are supported out of the box and you may have to write your own methods in order to make some gestures work. Some people find this annoying.
As of now it supports Android, iOS and even Firfox OS but doesn’t support Windows Mobile
Appium doesn’t have the ability to do image comparison. So if you are after something like that, tool like Sikuli may better suit your needs.
Fortunately, none of these limitations have been showstopper for us. But its good to be aware of both pros and cons before zeroing down on a particular tool.
As I said we have just started with Appium for last few months and there is still a long road ahead of us in order to achieve NIRAVANA
1st of all we need to migrate all our existing tests to Appium. Because we have a large number of tests written in the other tools which are absolutely valuable till we port them all into appium, we nee to have both the test frameworks in our pipelines.
We are making sure all new tests are being written in Appium.
Also, as and when we add new tests to appium we take a momemnt to review the existing tests to see if something got covered and we can get rid of those tests.
We have been running our tests on simulators and emulators in the pipelines. However, its always best to run your tests on a real device. Appium does support that. In order to achieve this in a scalable manner we are evaluating cloud service offerings to see which one suits us the best.
So there are more milestones for us to achieve but Appium certainly looks promising and seems to be the step in right direction.
I hope I ddnt bore you enough, feel free to ask questions now or get in touch via linkedin and I will be happy to help
Q. Can you test web view applications with appiu? A. Yes you can. Tests can be run in context of a webview, pretty much execute selenium tests on the mobile web view
Q. How scripts handle crashes? A. Scripts handle crashes by ending the session and you get an error code