Appium Interview Questions

What are the Advantages of using Appium?

  • It allows you to write tests against multiple mobile platforms using the same API.
  • You can write and run your tests using any language or test framework.
  • It is an open-source tool that you can easily contribute to.

Do I need Appium?

The answer to such a question is always: “It depends on what you need!”. So the actual question becomes: “Which conditions make Appium suitable for me?”. The most important assumption is that you are developing apps (pretty obvious I know). If you are developing an app for a specific platform (and have no intention of supporting others in future), Appium is not really required and this is basically the answer you are looking for. Appium becomes meaningful only when you have apps targeting more than one platform (Windows, Android or iOS to cite some). Appium becomes essential if you have a webview-based app (necessarily) targeting many platforms out there.

How difficult is it to set up a working environment?

The assumption is that Appium comes with a not-so-tiny documentation, so users are not really left alone. However it is not so straightforward to set up Appium to work on a Windows or Mac machine (did not try on Unix so far). In my experience, instead of installing the GUI-based application, it is much better to install the command-line application (which is released more often). Also beware [sudo], as Appium will surely bite you back late in time if you installed it as a [superuser] (this is probably the clearest point in the documentation)

What is Appium’s strongest point?

Appium is based on Selenium which is an HTTP protocol by Google designed to automate browsers. The idea is actually very nice as automating an app (especially a webview-based one) is not so different (in terms of required APIs) from automating a browser. Appium is also designed to encourage a 2-tier architecture: a machine runs the test written in one language ([csharp], [ruby], [javascript] are only a few among the many supported ones) and another one (the test server) actually executes it. Furthermore the WebDriver protocol targets scalability (because based on HTTP), this makes Appium very scalable as well; remember that you will need to write your test once, Appium will be in charge of executing it on more platforms.

What is Appium’s weakest point?

Open source software is great, however it naturally comes with some downsides which nobody is to be blamed for: unreliability is probably one of the most undeniable. My test suites need to run many tests every day and those tests must be stable (it means they should fail only when the product, or the test has a defect). However it took me much time to

build layers on top of Appium to make my tests stable. This is especially true when it comes to synchronizing your tests with the automation: your test issues a command which translates into an automation command by Appium causing an interaction on the device; a command returns when after it has been issued, not when the interaction is actually over! For this reason you will probably find yourself adding delays to your tests (if you are doing things in the wrong/most-straightforward way) or developing synchronization layers on top of your test APIs (the good approach).

What is the Appium Philosophy?

  • R1. Test the same app you submit to the marketplace
  • R2. Write your tests in any language, using any framework
  • R3. Use a standard automation specification and API
  • R4. Build a large and thriving open-source community effort

Why do the Appium clients exist?

We have the Appium clients for 3 reasons:

  • 1) There wasn’t time to go through a full commit and release cycle for Selenium once we’d set a release date for 1.0
  • 2) Some of the things that Appium does, and which its users really find useful, are never going to be an official part of the new mobile spec. We want a way to make these extensions available
  • 3) There are some behaviors whose state is as yet unknown. They might make it into the spec and get deleted from the clients, or they might be in category #2

Ultimately, the only reason for the clients will be #2. And even that is actually evidence that we are conforming to the WebDriver spec (by implementing the extension strategy it recommends) rather than departing from it. The Appium clients are the easiest and cleanest way to use Appium.

Explain what is Appium?

Appium is a freely distributed open source mobile application UI testing framework.

What are main Advantages of using Appium on Sauce Labs?

  • You save the time it takes to set up the Appium server locally.
  • You don’t have to install/configure the mobile emulators/simulators in your local environment.
  • You don’t have to make any modifications to the source code of your application.
  • You can start scaling your tests instantly.

Which language should I use to write my tests?

This is probably the best thing about Appium: you can write your tests in any language. Since Appium is nothing more than an HTTP server, a test which needs to be interfaced with Appium can simply use HTTP libraries to create HTTP sessions. You just need to know the Selenium protocol in order to compose the right commands and that’s it!

However, as you can imagine, there are already some libraries doing this for the most common languages and development frameworks out there: C#, [dotnet], [java], Ruby, [python] and Javascript are just few examples; and they all are open source

What type of tests are suitable for Appium?

When it comes to testing, especially webview-based apps, there are a lot of scenarios that can be tested also depending on the feature coverage you want to ensure. Appium is pretty handy for testing scenarios that users will go through when using your app. But if you need to test more than UX simple interactions, then Appium will become a limitation. Think about features like keyboarding. It is not so easy when complex touch/keyboard mixed scenarios are involved, the probability of a false failure is high; do not misunderstand me on this: I am not saying it is impossible to do, just not so easy as you might think!

Another little nightmare with Appium is exchanging data. When your test needs to exchange data with your app (especially in the incoming direction), you will need to play some tricks. So always consider that sending and receiving information is not that straightforward. It is not Appium’s fault, the WebDriver specification was designed for automating stuff, not exchanging data!

Can Appium be used for all my tests?

This is an implied question in this question. The answer is No (in general). As I said before Appium is not suitable for all types of tests you might want to write (this depends on the functionalities you need to cover). There are some scenarios that can be difficult to test and some of them are so platform specific that you will need to write some suites just for Android or iOS for example. Remember that you can always get to do something no matter how hard it is, so you can test all your difficult scenarios using Appium, but always keep in mind one question: is it worth the time and the pain? Having Appium testing some scenarios leaving a few tests to other approaches is fine too! World is not black and white!

List out the Appium abilities?

Appium abilities are

  • Test Web
  • Provides cross-platform for Native and Hybrid mobile automation
  • Support JSON wire protocol
  • It does not require recompilation of App
  • Support automation test on physical device as well as similar or emulator both
  • It has no dependency on mobile device

List out the pre-requisite to use APPIUM?

Pre-requisite to use APPIUM is

  • ANDROID SDK
  • JDK
  • TestNG
  • Eclipse
  • Selenium Server JAR
  • Webdriver Language Binding Library
  • APPIUM for Windows
  • APK App Info On Google Play
  • Js

What is Appium’s most considerable limitation?

Hand down my chin starting thinking and mumbling. If I had to provide one single thing you should be aware of about Appium before starting using it, it would surely be: multiple session handling. Since Appium is a server, it serves HTTP requests; you might have two different computers running a test each against the same Appium server: what happens? As for now, Appium does not support this scenario and the second test will be aborted. This is a considerable limitation, because no queuing system comes with Appium. If you need to support multiple sessions, you will need to implement this feature by yourself.

How active is Appium?

Appium is available on GitHub and there you can find all you need. The Appium team is responsible for developing many different subsystems revolving around Appium (like APIs for different languages), thus I can tell you that this product is alive and very active. The team is also pretty well responsive and once you open an issue you will find a reply after no more than 36 hours (this ETA comes by my personal experience). The community around Appium is also pretty large and growing every month.

What about performance?

Appium is not a huge application and requires very little memory. Its architecture is actually pretty simple and light as Appium acts like a proxy between your test machine and each platform automation toolkit. Once up and running, Appium will listen to HTTP requests from your tests; when a new session is created, a component in Appium’s Node.js code called _proxy_ will forward these Selenium commands to active platform drivers. In the case of Android for example, Appium will forward incoming commands to the [chromedriver] (90% of cases, Appium will not even change commands while routing them), this happens because ChromeDriver supports WebDriver and Selenium. For this reason Appium will not allocate much memory itself, you will see a lot of memory being allocated by other processes like [adb], ChromeDriver or the iOS automation toolkit (called by Appium while testing and automating).

Which approach is the best? Testing on real devices or simulators/emulators?

This is a tough question because both options offer different levels of testability and flexibility when testing. There are also many problems associated with each. So my answer will be again: “It depends on your needs!”.

Running test on a device is, always in my opinion, the best solution because it offers a testing environment completely aligned with the running environment: tests run on those devices where your apps will be used  once published on stores. However devices must be connected to the Appium server via USB at least, and this is not always a very nice thing. ADB has a known issue for which a device disconnects after a while (even though it remained plugged all the time): because of this your tests might fail after a while and Appium will report that a device could not be found! I had to write a component which resets ADB after some time so that devices will not disconnect.

Tests on emulators or simulators?

On the other hand emulators/simulators will never disconnect from Appium. They also offer nice options like the ability of choosing the orientation or other hardware-related configurations. However your tests will run much slower (sadly, my tests ran 3 times slower) and do expect some crazy behavior from the Android emulator which sometimes shuts down unexpectedly. Another problem is that emulators tend to allocate a lot of memory.

What platforms are supported?

Appium currently supports Android and iOS, no support for Windows unfortunately.

Do I need a server machine to run tests on Appium?

No! Appium promotes a 2-tier architecture where a test machine connects to a test server running Appium and automating the whole thing. However this configuration is not mandatory, you can have Appium running on the same machine where your test runs. Instead of connecting to a remote host, your test will connect to Appium using the loopback address.

List out the limitations of using Appium?

  • Appium does not support testing of Android Version lower than 4.2
  • Limited support for hybrid app testing. E.g., not possible to test the switching action of application from the web app to native and vice-versa
  • No support to run Appium Inspector on Microsoft Windows

How can I test Android tablets?

The best way to test on different Android emulators screen sizes is by using the different Android Emulator Skins . For instance, if you use our Platforms Configurator you’ll see the available skins for the different Android versions (e.g Google Nexus 7 HD, LG Nexus 4, Samsung Galaxy Nexus, Samsung Galaxy S3, etc). Some of these skins are tablets, for example the Google Nexus 7C is a tablet which has a very large resolution and very high density.

How can I run manual tests for my mobile native app or mobile hybrid app?

Sauce Labs doesn’t support manual tests for mobile native app or mobile hybrid app tests.

What type of keyboard and buttons do the Android emulators have?

Android Emulators have software buttons and a hardware keyboard. In a regular Android emulator the device buttons are software buttons displayed on the right size of the emulator. For the Android emulators with different skins (e.g Google Nexus 7 HD, LG Nexus 4, Samsung Galaxy Nexus, Samsung Galaxy S3, etc) the device buttons are also software buttons that are overplayed on top of the skin. For instance, if you hover the mouse around the edges of any of our Android emulators with an specified skin, a hover icon will appear and you should be able to find whatever buttons actually exist on the device that the skinned emulator is trying to emulate (e.g power button along the top, volume buttons along the edge, back/home buttons right below the screen, etc).

Explain how to find DOM element or xPath in a mobile application?

To find the DOM element use “UIAutomateviewer” to find DOM element for Android application.

Explain the design concept of Appium?

  • Appium is an “HTTP Server” written using Node.js platform and drives iOS and Android session using Webdriver JSON wire protocol. Hence, before initializing the Appium Server, Node.js must be pre-installed on the system
  • When Appium is downloaded and installed, then a server is setup on our machine that exposes a REST API
  • It receives connection and command request from the client and execute that command on mobile devices (Android / iOS)
  • It responds back with HTTP responses. Again, to execute this request, it uses the mobile test automation frameworks to drive the user interface of the apps. Framework like
  • Apple Instruments for iOS (Instruments are available only in Xcode 3.0 or later with OS X v10.5 and later)
  • Google UIAutomator for Android API level 16 or higher
  • Selendroid for Android API level 15 or less

What language does Appium support?

  • Appium support any language that support HTTP request like Java, JavaScript with Node.js, Python, Ruby, PHP, Perl, etc.

Explain the pros and cons of Appium?

Pros:

  • For programmer irrespective of the platform, he is automating ( Android or iOS) all the complexities will remain under single Appium server
  • It opens the door to cross-platform mobile testing which means the same test would work on multiple platforms
  • Appium does not require extra components in your App to make it automation friendly
  • It can automate Hybrid, Web and Native mobile applications

Cons:

  • Running scripts on multiple iOS simulators at the same time is possible with Appium
  • It uses UIAutomator for Android Automation which supports only Android SDK platform, API 16 or higher and to support the older API’s they have used another open source library called Selendroid

I already have platform-specific tests for my app, what should I do to migrate to Appium?

Unfortunately there is not a magic formula to translate your tests into Selenium tests. If you developed a test framework on different layers and observed good programming principles, you should be able to act on some components in your tests in order to migrate your suites to Appium. Your current tests are going to be easy to migrate if they are already using an automation framework or something close to a command-based interaction. Truth being told, you will probably need to write your tests from the beginning, what you can do is actually reusing your existing components

How much time does it take to write a test in Appium?

Of course it depends by the test. If your test simply runs a scenario, it will take as many commands as the number of interactions needed to be performed (thus very few lines). If you are trying to exchange data, then your test will take more time for sure and the test will also become difficult to read.

Any tips or tricks to speed up my test writing activity or my migration process?

Here is one piece of advice. Since your tests will mostly consist in automation tasks (if this condition is not met, you might want to reconsider using Appium), make interactions reusable! Do not write the same sub-scenarios twice in your tests, make a diagram of what your scenarios are and split them in sub activities; you will get a graph where some nodes are reachable from more than one node. So make those tasks parametric and call them in your tests! This will make your test writing experience better even when you need to migrate from existing tests (hopefully you already did this activity for your existing suites).

What test frameworks are supported by Appium?

Appium does not support test frameworks because there is no need to support them! You can use Appium with all test frameworks you want. NUnit and .NET Unit Test Framework are just a few examples; you will write your tests using one of the drivers for Appium; thus your tests will interface with Appium just in terms of an external dependency. Use whatever test framework you want!

Can I interact with my apps using Javascript while I am testing with Appium?

Yes! Selenium has commands to execute Javascript instructions on yourapp from your tests. Basically you can send a JS script from your test to your app; when the commands runs on Appium, the server will send the script to your app wrapped into an anonymous function to be executed.

Is it Returning the values?

However your Javascript interaction can get more advanced as your script can return a value which will be delivered to your test when the HTTP response is sent back by Appium once your Javascript has finished running. However this scenario comes with a limitation: your Javascript can send back only primitive types (integers, strings), not complex objects. The limitation can be overtaken by passing objects as JSON strings or by modifying Appium’s or Selenium’s code to support specific objects.

How can I exchange data between my test and the app I am testing?

Appium, actually the WebDriver specification, is not made for exchanging data with your app, it is made to automate it. For this reason, you will probably be surprised in finding data exchange not so easy. Actually it is not impossible to exchange data with your app , however it will require you to build more layers of testability.

What data exchange is?

When I say “data exchange” I am not referring to scenarios like getting or setting the value of a textbox. I am also not referring to getting or setting the value of an element’s attribute. All these things are easy to achieve in Appium as Selenium provides commands just for those. By “data exchange” I mean exchanging information hosted by complex objects stored in different parts of your webview-based app like the window object. Consider when you dispatch and capture events, your app can possibly do many things and the ways data flows can be handled are many. Some objects might also have a state and the state machine behind some scenarios in your app can be large and articulated. For all these reasons you might experience problems when testing.

What are Testability layers?

In order to make things better, as a developer, what you can do is adding testability layers to your app. The logic behind this approach is simply having some test-related objects in your app which are activated only when your tests run. I learned about this strategy from one of my colleagues Lukasz and such a technique can be really powerful. Enable your testability layers when testing in order to make data exchange easy.

Is it Exchanging data through Javascript?

Selenium provides commands do execute Javascript on the app, it is also possible to execute functions and have them return data (only basic types). If you exchange JSON strings it should be fine as JSON.stringify(str) will turn your JSON string into an object on the app side, while on the test side (depending on the language you are using), you can rely on hundreds of libraries to parse the string you receive.

What are the most difficult scenarios to test with Appium?

Appium is not suitable for all types of tests. There is a particular scenario that will make your tests more difficult to write: data exchange. I already said it but I will repeat the same thing because it is very important: Appium and WebDriver are designed to automate stuff… not to exchange data with them. So what if we need to exchange information with our app during tests? Should we give up on Appium and write our tests manually for each platform? I am not saying this, but there are cases where you should consider this option (not nice I know, but if the effort of writing tests for Appium is higher than the benefits, than just throw Appium away).

Appium is very nice because it will let you write tests once for all platofrms instead of writing as many tests as the numbers of platforms you need to support. So if you need to exchange data with your app while testing it and this data flow is the same for all platforms, then you should probably keep on using Appium and find a way to write a layer on top of it to handle data. Depending on your needs this might take time, but, in my experience, it is really worth it.

I don’t want to set up a whole infrastructure for my tests and I don’t want to spend money on HW. Can Appium help me?

If you think about it, what really is required from you is writing tests. Then the fact that you must deploy an Appium server somewhere is something more. If you want to skip this part, you can rely on some web services that already deployed a whole architecture of Appium servers for your tests. Most of them are online labs and they support Selenium and Appium.

I need to debug Appium, is it difficult?

No really! Appium is a Node.js application, so it is Javascript in the essence. Depending on what you have to debug, you will probably need to go deeper in your debugging experience, however there are some key points where setting a breakpoint is always worth: the proxy component is worth a mention. In appium/lib/server/proxy.js you can set a breakpoint in function doProxy(req,res), that will be hit everytime commands are sent to platform-specific components to be translated into automation

I build my apps with Cordova, is it supported by Appium?

Cordova is a very famous system that enables you to develop webview-based apps for all platforms in short time. Appium does not explicitely say that Cordova is supported, even though they do it implicitely as some examples using apps built with Cordova are provided on Appium’s website. So the answer is that Cordova should not be a problem. Why am I being so shy about it? Because anything can happen and it actually happened to me!

Cordova and Appium are two different projects that are growing up separately and independently, of course a mutual acknowledgement is present, but both teams do not really talk to each other when pushing features. So problems can occur (I am currently dealing with a problem concerning Cordova’s new version which is causing my tests to fail).

Explain what is APPIUM INSPECTOR?

Similar to Selenium IDE record and Playback tool, Appium has an “Inspector” to record and playback.  It records and plays native application behavior by inspecting DOM and generates the test scripts in any desired language.  However, Appium Inspector does not support Windows and use UIAutomator viewer in its option.

What are the basic commands that I can use in the Selenium protocol?

Google’s Selenium provides a collection of commands to automate your app. With those commands you can basically do the following:

  • Locate web elements in your webview-based app’s pages by using their ids or class names.
  • Raise events on located elements like Click().
  • Type inside textboxes.
  • Get or set located element’s attributes.
  • Execute some Javascript code.
  • Change the context in order to test the native part of your app, or the webview. If your app uses more webviews, you can switch the context to the webview you desire. If your webview has frames or iframes inside, you can change context to one of them.
  • Detect alert boxes and dismiss or accept them. Be careful about this functionality, I experienced some problems.

I want to run my tests in a multi threaded environment, any problems with that?

Yes! You need some special care when using Appium in a multithreaded environment. The problem does not really rely on the fact of using threads in your tests: you can use them but you must ensure that no more than one test runs at the same time against the same Appium server. As I mentioned, Appium does not support multiple sessions, and unless you implemented an additional layer on top of it to handle this case, some tests might fail.

Mention what are the basic requirement for writing Appium tests?

For writing Appium tests you require,

  • Driver Client: Appium drives mobile applications as though it were a user. Using a client library you write your Appium tests which wrap your test steps and sends to the Appium server over HTTP.
  • Appium Session: You have to first initialize a session, as such Appium test takes place in the session. Once the Automation is done for one session, it can be ended and wait for another session
  • Desired Capabilities: To initialize an Appium session you need to define certain parameters known as “desired capabilities” like PlatformName, PlatformVersion, Device Name and so on. It specifies the kind of automation one requires from the Appium server.
  • Driver Commands: You can write your test steps using a large and expressive vocabulary of commands.

How can I run Android tests without Appium?

For older versions of Android Appium might not be supported. For instance, Appium is only supported in Android versions 4.4 or later for Mobile Web Application tests, and Android versions 2.3, 4.0 and later for Mobile Native Application and Mobile Hybrid Application tests.

For those versions in which Appium is not supported you can request an emulator driven by Webdriver + Selendroid. All you need to do is use our Platforms Configurator and select Selenium for the API instead of Appium.

In the Sauce Labs test you will notice that the top of the emulator says “AndroidDriver Webview App”. In addition, you will notice that you will get a “Selenium Log” tab which has the output of the Selendroid driver.

With an emulator driven by Webdriver + Selendroid you will be able to test Mobile Web Application only. You should be able to select any Android emulator version from 4.0 to the latest version and any Android emulator skin (e.g “deviceName”:”Samsung Galaxy Tab 3 Emulator”).

How can I run iOS tests without Appium?

For older versions of iOS Appium might not be supported. For instance, Appium is supported in iOS versions 6.1 and later. For earlier versions of iOS the tool or driver used to drive your mobile applications automated test is called iWebdriver.

To obtain a simulator driven by iWebdriver use our Platforms Configurator and select Selenium for the API instead of Appium. With an emulator driven by iWebdriver you will be able to test Mobile Web Application only. In addition, in the Sauce Labs test you will notice a “Selenium Log” tab which has the output of iWebdriver.

What mobile web browsers can I automate in the Android emulator?

Currently the only browser that can be automated in our Android emulators is the stock browser (i.e Browser). The Android stock browser is an Android flavor of ‘chromium’ which presumably implies that its behavior is closer to that of Google Chrome.

Explain what is Appium?

Appium is a freely distributed open source mobile application UI Testing framework.

List out the Appium abilities?

Appium abilities are

  • Test Web
  • Provides cross-platform for Native and Hybrid mobile automation
  • Support JSON wire protocol
  • It does not require recompilation of App
  • Support automation test on physical device as well as similar or emulator both
  • It has no dependency on mobile device

List out the pre-requisite to use APPIUM?

Pre-requisite to use APPIUM is

  • ANDROID SDK
  • JDK
  • TestNG
  • Eclipse
  • Selenium Server JAR
  • Webdriver Language Binding Library
  • APPIUM for Windows
  • APK App Info On Google Play
  • js

List out the limitations of using Appium?

  • Appium does not support testing of Android Version lower than 4.2
  • Limited support for hybrid app testing. E.g., not possible to test the switching action of application from the web app to native and vice-versa
  • No support to run Appium Inspector on Microsoft Windows

Explain how to find DOM element or xPath in a mobile application?

To find the DOM element use “UIAutomateviewer” to find DOM element for Android application.

Explain the design concept of Appium?

  • Appium is an “HTTP Server” written using  Node.js  platform and drives iOS and Android session using Webdriver JSON wire protocol. Hence, before initializing the Appium Server, Node.js must be pre-installed on the system
  • When Appium is downloaded and installed, then a server is setup on our machine that exposes a REST API
  • It receives connection and command request from the client and execute that command on mobile devices (Android / iOS)
  • It responds back with HTTP responses. Again, to execute this request, it uses the mobile test automation frameworks to drive the user interface of the apps. Framework like
    • Apple Instruments for iOS (Instruments are available only in Xcode 3.0 or later with OS X v10.5 and later)
    • Google UIAutomator for Android API level 16 or higher
    • Selendroid for Android API level 15 or less

What language does Appium support?

Appium support any language that support HTTP request like Java, JavaScript with Node.js, Python, Ruby, PHP, Perl, etc.

Explain the pros and cons of Appium?

Pros:

  • For programmer irrespective of the platform, he is automating ( Android or iOS) all the complexities will remain under single Appium server
  • It opens the door to cross-platform mobile testing which means the same test would work on multiple platforms
  • Appium does not require extra components in your App to make it automation friendly
  • It can automate Hybrid, Web and Native mobile applications

Cons:

  • Running scripts on multiple iOS simulators at the same time is possible with Appium
  • It uses UIAutomator for Android Automation which supports only Android SDK platform, API 16 or higher and to support the older API’s they have used another open source library called Selendroid

Explain what is APPIUM INSPECTOR?

Similar to Selenium IDE record and Playback tool, Appium has an “Inspector” to record and playback. It records and plays native application behavior by inspecting DOM and generates the test scripts in any desired language. However, Appium Inspector does not support Windows and use UIAutomator viewer in its option.

Mention what are the basic requirement for writing Appium tests?

For writing Appium tests you require,

  • Driver Client: Appium drives mobile applications as though it were a user. Using a client library you write your Appium tests which wrap your test steps and sends to the Appium server over HTTP.
  • Appium Session: You have to first initialize a session, as such Appium test takes place in the session. Once the Automation is done for one session, it can be ended and wait for another session
  • Desired Capabilities: To initialize an Appium session you need to define certain parameters known as “desired capabilities” like PlatformName, PlatformVersion, Device Name and so on. It specifies the kind of automation one requires from the Appium server.
  • Driver Commands: You can write your test steps using a large and expressive vocabulary of commands.

Mention what are the possible errors one might encounter using Appium?

The possible errors one might face in Appium includes

  • Error 1: The following desired capabilities are needed but not provided: Device Name, platformName
  • Error 2: Could not find adb. Please set the ANDROID_HOME environment variable with the Android SDK root directory path
  • Error 3: openqa.selenium.SessionNotCreatedException: A new session could not be created
  • Error 4: How to find DOM element or XPath in a mobile application?

Do you need a server machine to run tests on Appium?

No, you don’t need server machine to run tests on Appium. Appium facilitates a 2-tier architecture where a test machine connects to a test server running Appium and automating the whole thing. You can have Appium running on the same machine where your test runs.

Is it possible to interact with my apps using Javascript while I am testing with Appium?

Yes, it is possible to interact with App while using Javascript. When the commands run on Appium, the server will send the script to your app wrapped into an anonymous function to be executed.

Mention what are the most difficult scenarios to test with Appium?

The most difficult scenario to test with Appium is data exchange.

While using Appium can I run my tests in a multithreaded environment?

Yes, you can run the test in a multithreaded environment but you have to ensure that no more than one test runs at the same time against the same Appium server.

In Android, do you need an app’s .apk to automate using Appium or you also need app in my workspace?

In Android, you only need .apk file to automate using Appium.

Explain what is Appium package master? How to create package?

Appium package master is a set of tools manage and create appium packages. For example to create package you can use the code

# using es7/babe1

Gulp create-package –n <package-name>

#regular es5

Gulp create-package —nobabe1 –n <package-name>

The package will be generated in the out/<package-name>

Explain how test frameworks are supported by Appium?

Appium does not support test framework as such there is no need to support them. Appium can be used with any frameworks you want.

What is Appium Mobile Automation Tool?

Appium is a mobile automation tools. Mobile automation here refers to the automation of mobile applications. Applications may be Native apps, Mobile web apps or Hybrid apps. Appium is cross-platform and open source tool.

Cross-platform means we can write tests in appium in multiple platforms i.e. android and ios using the same API. Thus, we can use the same code to run our test suite on iOS or Android platforms. It’s one of the most useful advantage of Appium tool.

How Appium Setup is done on Android Devices?

Using Appium on Android devices has some pre-requisites. You need to have following in order to use appium for android:

JDK 7 or higher – Install JDK first on your system

Android SDK – Install Android SDK version 17 or higher on your system

Packages – Install any required package for you Android platform version in the Android SDK Manager

AVD – Android Virtual Device is an emulator that is similar to the android device

Appium.exe/ Appium.app  – Install Appium executable on your system which provides a GUI based tool available for using appium. If you wish to use the latest Appium, install Appium from Source and run it from the command line.

Explain Appium architecture?

At the heart of Appium lies a web server that exposes a REST API -receives connections from a client, listens for commands, executes those commands on a mobile device and responds with an HTTP response representing the result of the command execution.

Since it’s a client server architecture, there are numerous possibilities of using writing test code in our preferred language that consist of http client API. Thus, you can use any of the option from the available Appium client libraries to write your test code.

What are limitations of Appium ?

Below are few limitations or challenges of Appium:

  • It takes lot of initial efforts for configuring appium both on Android and iOS platforms
  • Image comparison is not possible using Appium
  • Unexpected errors are observed quite often which sometimes takes time for resolution
  • Android API level < 17 is not supported by Appium (Selendroid needs to be used otherwise)
  • Execution of scripts is slow on iOS platform
  • Limited gesture support is available in Appium.

Should we test apps on real devices or on simulators, which is more preferable?

 It’s preferable always to test the applications on real devices. However, due to the increasing number of devices, it’s quite difficult to test the applications on every new device, thus it’s much better to use emulators in such cases. Emulators configuration is easy and quick.

Hence, if the device is available it’s better to use the device only otherwise go for Emulator.

What are the languages supported by Appium?

  • Objective C
  • Javascript with Node.js
  • PHP
  • Python
  • Ruby
  • C#
  • Clojure
  • Perl

How do we identify elements of any mobile app using Appium?

You can use Appium Inspector which is a GUI based tool similar to Selenium IDE. It shows the hierarchy of the mobile application elements that is being automated. So you can get all the properties for each element using the inspector.

Can we use Javascript in Appium to perform app automation?

Yes, we can use JavaScript to automate applications using Appium. Any language that supports HTTP request can be used with Appium. The reason behind this is simple, Appium is an Http server thus it accepts http request in the form of Http sessions for execution of Appium commands.

Other languages like Java, Ruby, PHP, Python, Perl, Node.js are other examples of the languages which support Http request.

What type of Mobile apps can be automated using Appium?

 You can automate Native, Web and Hybrid mobile applications using Appium.

Can we perform Parallel tests using Appium?

We can set multiple Android sessions on a single machine using Appium. All you have to do is to start multiple Appium servers with different flags. There are number of important flags for automating multiple android session on the system:

-p :  the main Appium port

-U : the device id

-bp :  the appium bootstrap port

–chromedriver-port : the chromedriver port (if you are using webviews or chrome)

–selendroid-port: the selendroid port (if you are using selendroid)

For automating 2 devices with IDs 12345 and 54321, you need to use the below commands to achieve parallel testing.

node -p 4492 -bp 2251 -U 54321

node -p 4491 -bp 2252 -U 12345

As long as your Appium and Appium bootstrap ports lie in the range of 0 to 65536, the only requirement is that these port should be different so that the appium servers listen to different ports. You need to make sure that you use -u flag with the correct device id. Appium can connect to unique device in this way only.

For chromedriver or selendroid, you need to set different port for each server.

# In order to perform parallel testing on iOS device, you have to use Sauce since appium doesn’t have a direct support for parallel testing on iOS devices.

What are Appium.app and Appium.exe?

Appium supports desktop apps on OS X and Windows using Appium.app and Appium.exe. There are ready to run versions of Appium. There is no need to run the source code if we use these executable files directly on the system.

These executables are primarily GUI wrappers around the Appium server. These files contains everything that is required to run the Appium server including the Appium Inspector. Thus there is no need to go into the technicality of Node.

What is fruitstrap. What is its use?

Fruitstrap is a third-party tool to deploy the application build on a real iOS devices. For automation, Appium installs the testing application on the iOS device using Fruitstrap.

Can mobile gestures be automated using Appium?

Yes, Mobile gestures can be automated using Appium. Using TouchActions api, mobile gestures can be automated. TouchActions is similar to Actions class in Selenium. In addition, JSON wire protocol extensions are also enabled in TouchActions.

Gestures like tap, flick, swipe, scroll, shake can be automated using appium.

What is the default port number used for Appium Server?

Default port number used for Appium Server is 4723. You need to mention the same while writing desired capabilities in the initial lines of code.

Name the Appium Client Libraries?

Java, Ruby, Python, PHP, Javascript(Node.js) and C# are the appium client libraries used for extension to the WebDriver protocol. You can use these libraries in order to use your favorite language for automating your mobile application.

What are Appium Desired Capabilities and what are they used for?

Desired capabilities are nothing but a kind of SET data structure as we use in Java. It may be a Map or Hash. Basically, these are used to send sets of keys and values to the Appium server to let it know what kind of automation session we want to start up.

Also the desired capabilities can be used to modify the server behavior while automation is running.

Few of the commonly used desired capabilities are:

  • platformName: To notify the appium server the platform we will be using for automation (e.g. values you can use are android/ios etc)
  • autoLaunch: To notify Appium server whether to automatically install and launch the application or not.
  • browserName: To notify the name of mobile web browser to be used for automation. If you are not using any app, keep the value as empty string.
  • safariAllowPopups: To allow use of Javascript popups while using Safari automation session.

What is the limitation of running Appium on Linux?

You can’t install .app executable on Linux machine. It means that you won’t be able to test iOS applications using Appium on a Linux machine.

How to debug appium tests?

Debugging Appium tests is not a very difficult task. Its a Node.js application. Thus, in its core it has javascript. The free source code can be downloaded from the Github. Debugging deeper is required sometimes if the issue is complex. One way to go for easy debugging is to set breakpoint at key points. For e.g. setting a breakpoint for the “proxy” component. In the source code, refer from the file from the path “appium/lib/server/proxy.js” set a breakpoint for the function doProxy(req,res). This will enable the compiler to hit at this breakpoint every time the commands are sent to platform-specific components. The are the commands which gets converted into automation commands.

Can we do data exchange using Appium?

This is one of the weakest point of Appium. The data exchange part is quite a complex task to perform using Appium. Simple data exchange is possible easily using the available Appium and Selenium APIs like writing data in the fields etc. However for complex data exchange such as fetching the state of application or data exchange by complex objects in the web-view of applications, Appium is not much useful for such cases and it’s a better approach to go for manually writing the test cases specific to every platform.

Mention the possible errors you might encounter while using Appium?

Below are few error examples which are usually observed in Appium.

  • Failed to start Appium session, Instruments did not launch successfully
  • Android hybrid mobile app: Getting Unhandled error: Error: getaddrinfo ENOENT in appium, wherein a session could not be created #6610
  • Appium v1.3.0-beta1 & xCode 6.1, Failed looking up pid of launched process
  • Clicking on Inspector icon nothing is happening
  • error: Failed to start an Appium session, err was: Error: Could not find zipalign in tools, platform-tools, or supported build-tools under “/Applications/AndroidStudio.app/sdk”; do you have android SDK or build-tools installed into this location? Supported build tools are: 17.0.0, 18.0.1, 19.0.0, 19.0.1, android-4.2.2, android-4.3, android-4.4

You might face similar errors even more while using Appium. An automation engineer is always expected to solve such issues. In order to resolve the issues, google such issues first or try to do some changes in your code and do trial and error or look for some configuration changes which might resolve the issues.

Explain Appium Philosophy. In other words, what are the main principles on which Appium mobile automation is based upon?

Appium was basically built up for mobile automation. To meet  the requirements of mobile automation, four principles were followed upon. These principles are called nothing but Appium Philosophy. These are:

  1. For automating your mobile application, you should not be required to recompile or modify it in any form.

It means you should be able to automate the mobile application in the same state in

which it is built up originally without doing any changes or modifications in it.

  1. There should not be any binding of any specific language usage or usage of any

specific framework in order to automate your mobile application using Appium.

  1.    No need of any new APIs for Appium. There should not be any need to create new

Set of APIs for Appium. It should be possible to use any existing API set to automate

mobile applications (Thus the use of Selenium Webdriver APIs in Appium happened)

  1.    The concept of Open Source should be in existence for the mobile automation

Framework built. There should be no bindings on the framework usage and its

code should open source so that anyone can use it.

Is it difficult to do Appium Setup?

The real answer to this question is Yes. Initially you may find setting up the Appium environment quite tedious. However, once understood, you will find it quite easy to setup appium as per your needs.

Setup differs with the operation system like Android and iOS and there are several things to be taken care of while configuring appium such as using proper values in desired capabilities, providing proper device ids etc.

Does Appium requires a Server Machine to be used?

No, Appium doesn’t require any server machine in order to perform automation. It’s a client based architecture wherein both the test client and the test server can be setup on a single system thereby avoiding the need of any kind of remote machine acting as a server.

Mention one of the critical thing to automate using appium?

Data exchange is one of the critical area for Appium since Appium is not designed in a way to exchange complex data. Sending data in the app is possible using Appium but exchange of data between complex objects of webview of the application is quite a critical thing to do using Appium.

Summary
Review Date
Reviewed Item
Thank you for Sharing Appium Interview Questions, Very Helpful! Please Keep Adding more Appium Interview Questions.
Author Rating
51star1star1star1star1star