Appium and Selenium are great tools, which allows interaction with and manipulation of mobile devices. Both are cross-platform tools, meaning they work for automating across multiple devices; Appium for both iOS and Android and Selenium for multiple OS and browser combinations. Appium and Selenium are both built on top of WebDriver, similar to Protractor, and many other tools, and supports having tests written in multiple languages. While these tools can be used standalone, writing a framework around them adds multiple benefits, including simplicity in execution, more maintainable code, robustness of execution, additional logging, and simple iOS to Android cross test compatibility.
Any written code needs some way to be executed. For tests, multiple frameworks exist which make it easy to write, and run tests in parallel. Issues like threading, execution, parameterization, and more are common features of most testing frameworks. Most typical is the usage of xUnit frameworks, such as JUnit or nUnit, as these integrate seamlessly into build tools, and most developers and SDETs (Software Development Engineers in Test) are intimately familiar with these. These frameworks are very extensible, which can then allow for additional benefits to be granted by the framework.
When writing any WebDriver based tool test, it’s best to follow the Page Object Model (POM). This keeps your locators (used to interact with elements) in one place and reduces redundancy of their occurrences. Without a framework in place with this code, management quickly becomes difficult for the code base. A properly chosen framework can simplify this maintenance aspect even further.
One major drawback to WebDriver is that its interaction with elements is brittle. If an element is attempted to be clicked upon but isn’t present, the test will crash, exit early, and not provide much useful information, other than that the element is missing. Utilizing a framework makes it easy to start wrapping these WebDriver calls, to make these calls more robust. Instead of just clicking on elements, you can first check if the element exists and/or is clickable. The benefits of a robust framework mean that the click command can be easily overridden so that these additional checks don’t need to be written with each and every interaction.
In addition to adding robustness to elements, a framework can provide an easy way to beef up logging. WebDriver by default can be run with multiple log levels but doesn’t provide any logging that is easy to go through. Commands can again be overloaded to provide more detailed logs, and even given screenshots as well, without have to write additional commands. Multiple frameworks support taking screenshots upon completion of tests, and others provide the ability to take a screenshot after each step.
While Appium alone can handle both iOS and Android, often times the workflows may differ some, the interactions need to differ some, or the locators may differ from one platform to the next. Additionally, since Selenium 3.X has separate APIs for interacting with each browser, common interaction method implementations may vary from browser to browser. For this reason, while you may want to run the same tests, different implementations might need to exist. Frameworks can help setup interfaces for defining device or browser specific implementations, and make tests more compatible with less code and less effort.
When combining multiple tools, using a framework becomes even more beneficial. Similar to using a framework to help make tests more cross device compatible, when looking to expand tests to cover browsers, this cross device compatibility can be extended. One test can be written, with the framework selecting browsers/devices to test on, and handling the setting up of interfaces to manage which device implementation to select. Additionally, tools such as dependency injectors can be easily integrated in to simplify code, and make it cleaner to organize and read.
So, what should the overall takeaway be from this? Consider your tooling, and testing requirements, and start looking for a framework that fits your needs. I give a great talk ‘Exploring Automation Strategies and Frameworks What Should Your Team Be Using?’ which dives into a lot of questions which can help you choose the correct framework, to most effectively accomplish the above benefits; see if I’m giving it anywhere near you.
And of course, be sure to checkout Selenified. It provides mechanisms for simply testing applications at multiple tiers while easily integrating into DevOps build environments. Selenified provides traceable reporting for both web and API testing, wraps and extends Selenium calls to more appropriately handle testing errors, and supports testing over multiple browsers locally, or in the cloud (Selenium Grid or SauceLabs) in parallel. It can be a great starting point for building or improving test automation in your organization.