Mobile App Testing: A Brave New World
Below, the author compares Appium to Selenium, and explains how you can make the most of whichever tool you decide to use.
Join the DZone community and get the full member experience.
Join For FreeIs mobile application testing any different than normal software testing? While software testers' lives might be easier if the answer to that question were "no," that is not the case, of course.
Mobile testing is different in all sorts of ways. You need to test for different things, and there is usually a wider range of devices to support when it comes to mobile.
But perhaps the biggest difference is that one of the most popular testing tools for mobile apps is Appium, whereas Selenium is more common for non-mobile testing. These tools work in different ways, with important implications for the level of automation you can introduce to your tests.
Below, I compare Appium to Selenium, and explain how you can make the most of whichever tool you decide to use.
Selenium
Selenium, the well-known web browser automation suite of tools, is an essential ingredient for testing because it automates browser testing.
This means Selenium is not only useful for automating tests for web applications - It also can automate online administration tasks. DevOps Engineers get two for the price of one by using Selenium.
You should understand, however, that Selenium is not just a single tool. It’s a suite of different tools, with two main functional parts:
- Selenium WebDriver
- Selenium IDE
Figure 1 below shows the characteristics of these two very functional tools for web browser testing.
Figure 1: The characteristics of the Selenium Suite: Selenium WebDriver and Selenium IDE (source)
Selenium is supported by the greatest number of browser vendors, and version 3.0 has just been released.
When you use Selenium WebDriver, you need to write your test scripts. You can write them in a WebDriver-compatible language such as Java and Objective-C, but you can also use JavaScript, Python, C# and many more.
Appium
The big drawback of Selenium, especially in today's mobile-centric world, is that Selenium itself was not designed for automating tests for mobile apps.
But fret not. This is where Appium comes in. Alongside Selendroid, Appium is a framework based on Selenium that was specially created for mobile automated testing.
Appium Philosophy
Appium is cross-platform. It is designed according to the following philosophy:
- You shouldn't have to recompile your app or modify it in any way in order to automate it.
- You shouldn't be locked into a specific language or framework to write and run your tests.
- A mobile automation framework shouldn't reinvent the wheel when it comes to automation APIs.
- A mobile automation framework should be open source, in spirit and practice as well as in name!
Appium Architecture
How does Appium architecture meet the Appium philosophy?
Appium is an HTTP webserver, written in Node.js using a REST API.
Recompiling apps is not necessary, because Appium utilizes vender-provided automation frameworks like Apple's UIAutomation or Google's UiAutomator. This way, the app you test is the app delivered.
Language- or framework-locking is excluded because the vendor-provided automation frameworks are wrapped in the WebDriver API. This API specifies a client-server protocol (JSON wire protocol). By using this, a client written in any language can be used to send the appropriate HTTP requests to the server. The clients are the "automation libraries," so you can manage your test environment as you like. There are client libraries (in Java, Ruby, Python, JavaScript etc.) which support Appium extensions to the WebDriver protocol. Reinventing the wheel is unnecessary because WebDriver is the standard for web browser automation. Just a few tweaks are needed to let it work on mobile.
Last but not least, Appium is open source. Complete information on the Appium architecture is freely available on GitHub.
Appium Sessions
A session is, in fact, the automation of your specific mobile browser test in Appium. Every client sends an HTTP POST-request to the server with a "desired capabilities"
object (a JSON object). Now, the server will start up the session and respond with a session ID which will be used further in the session.
Desired capabilities are a set of keys and values sent to the Appium server to tell the server what kind of automation session we're interested in starting up. There are also various capabilities which can modify the behavior of the server during automation. (See this capabilities document for the complete list of capabilities.)
As you can see, Appium is a great way to automate your mobile web application testing.
To get started, check out this video, where Appium is used for both iOS and Android testing:
Conclusion
Mobile application testing is very different from normal web application testing due to the various devices and versions of operating systems. But browser automation tools like Selenium can be used for mobile test automation by modifying the framework, similar to Appium.
Of course, whether you need to use Selenium or Appium, you can easily leverage both tools via Sauce Labs' cloud-based testing platform.
Appendix: Appium Vs. Selendroid
I mentioned Selendroid above. Explaining the details of how Selendroid varies from Appium would require a separate article, but the table below offers a quick summary:
Selendroid | Appium |
Tailor-made for Android | Cross-platform (Android & iOS); re-usable for both OS |
UI (User Interface) native, hybrid apps | UI native, hybrid & mobile web apps |
Stable on emulators & real devices | Usable on real devices & real browsers(!!) |
Scaling & parallel testing | Scaling & parallel testing |
Table 2: The characteristics of Selendroid vs. Appium (source)
Published at DZone with permission of Cordny Nederkoorn, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Trending
-
What ChatGPT Needs Is Context
-
Transactional Outbox Patterns Step by Step With Spring and Kotlin
-
Comparing Cloud Hosting vs. Self Hosting
-
Avoiding Pitfalls With Java Optional: Common Mistakes and How To Fix Them [Video]
Comments