A software application has to undergo multiple levels of testing to ensure its reliable functioning. To achieve this the product has to undergo rigorous testing. In agile testing methodology, when an application undergoes frequent changes, we need to ensure that the existing functionality or feature is working fine. It is really challenging and a cumbersome task when you wish to test your ever changing production code manually, in addition to that it will consume lot of time and won’t be cost effective.
So to achieve a reliable, quick and improved test coverage, many organizations are now adapting automation testing to run smoke, and regression tests for their desktop, web, and mobile applications. To make your test automation code reusable, maintainable and stable and then building an test automation framework would be the need of the hour.
What is a Framework?
When we think of automation, we invariably invest time, effort and money. One should be diligent enough while designing automation test framework, since any presumptuous decision will have serious repercussion in terms of escalated costs, lost time, and inferior product quality. Hence the automation framework should be carefully designed so as to incorporate libraries, test data and existing open source tools to facilitate high code reusability, maintainability and stability to perform seamless execution and to provide promising results.
Following are the some of the benefits of a robust automation testing framework
The entire team is aware of developing and maintaining the code base as per the set standards since the code is organized in well-defined packages and is properly structured
We can integrate different components that help the purpose of running the test cases, reporting the results and capturing the logs etc
Enhance the efficiency during design and development of automated test scripts by enabling the reuse of components or code
Reduce the expertise dependency by selecting the test to execute according to test scenarios and dynamically refining the test scope according to the changes.
Creating and maintenance of test cases is easier because test scripts for different modules can be reused.
Test scripts can be written independent of the software under test (SUT).
Framework can be reused for any similar projects internally within teams.
Components of Appium framework
Node ModulesInstalling node.js in your computer should be the starting point, because all other packages such as appium , appium-doctor can be installed through the npm install
Appium ServerAppium server is available in node modules, we can install this by executing the below command
npm install –g appium
Build ToolBuild tool helps us to build the code and then to execute it. Build tool helps us to manage the required dependencies needed for our project such as TestNG, Appium client, Selenium etc.
Few widely used build tools available in the market are – Maven, Gradle, & Ant. We can choose any one of them based on the project need, budget, and it’s completely left to the team’s discretion.
Selenium WebdriverAs discussed above, Appium uses selenium to communicate effectively with browsers that run on mobile devices, hence we need to have selenium jar files loaded into our project.
Test runnerIt is good to have test runners such as J-unit, N-unit, testing etc. in our projects. TestNG is widely used in test automation as it has several annotations to help us run tests in sequence.
JDKJava development kit is a must in order to develop any java application. Hence this should be installed from oracle official site. Appium has java support until Java 12.
Android SDKAndroid SDK is generally used to develop android applications, but from the test automation perspective we needn’t possess thorough knowledge on android studio. With these tools we can actually connect mobile device to the computer and understand several properties of it.
UI Automator2This tool is used to set the capabilities of the mobile device under test, therefore the device can be connected and the UI of it can be accessed. Using this, we can connect both the emulator and the real device. We can capture the application elements (locators) with the help of this tool.
Extent reportsExtent reports are used to report the test results in a more meaningful format. We can include the jar files into our project by adding these dependencies to our pom.xml file
VCS systemVersion controlling systems should go hand in hand with any software development or software test automation projects. VCS systems will greatly help the team in maintaining the new revision of code by including every change to the code base. With the help of this tool we can achieve backtracking, if needed it can also be integrated with CI/CD pipelines.
CI/CD systemModern practices adapt the CI/ CD pipeline in order to execute the tests automatically without any manual intervention. Jenkins, Teamcity, Azure DevOps are some good examples of build automation to achieve CI/ CD practice.
Framework ArchitectureSo far in this discourse, we have learnt the components that will complement and make Appium framework more versatile. We will see how to organize the code base in the rest of the article, this will in turn be considered as a best practice.
Folder StructureWhen any maven project is created, we get the below project template. Hence we need to ensure that we define proper guidelines to maintain the code base. Since it is a test automation project, it is okay to keep all the required java class files under src/test/java folder.
It is highly recommended to create a sub package for the wrapper functionalities and for the test cases as shown in the below snap, so that we can have a clean differentiation of test cases the build and associated functions.
All the driver exe files such as Android driver, IOS driver and windows drivers to be maintained in the driver folder, so that the team can have a common understanding of where those files reside and it would be easy for the script developers to update them when needed.
It is good to keep the test data to be maintained in CSV, excel in a separate folder called test data, so that the developers will make use of those and update it when required. For reports when the test case is executed, TestNG will create a test-output folder. We can see the TestNG html results files in there.
Design patternsDespite the project being a test automation project, design patterns must be adopted to make sure that the framework is more reusable which in turn reduce the maintenance effort. Below are some useful techniques to achieve the same.
POM ImplementationPage object model is one of the design techniques to separate the application page code from the test case code. This will avoid doing re-work when there are any changes done on the application screens.
POM class file will have page factory method implementation. Generally we will define each page as separate java class. We also find the needed locators that are associated to the particular page with the help of @findBy annotation.
Sample POM class file below:
Dependency injectionThis technique is used to pass the values between the class file without having them coupled. The dependent object receives the object value from the class object that it depends on. This can be helpful when we integrate Cucumber (BDD) with our Appium test. Since the hooks class can’t be extended by any other class, we use this concept to have the driver object shared to any step definition class that is available within the project.
Retry LogicWhile running Appium test cases we tend to observe a lot of events, a test can possibly be failed, skipped and ignored. We can have a test that is failed to run again. testNG listeners are greatly helpful to achieve this. We can try writing a logic to re-run the test case under the method (On test failure), we can also take a snapshot of the failed test cases for future reference.
Use of Property FilesWe give a lot of inputs to our Appium test cases such as platform, device name, device OS, UDID, app package name, app activity, path of the apk/.ipa file.. etc. Instead of providing the details directly in the test case, it is always good to fetch these information from a property file . This helps all the tests to use the same details when we are running the test cases against a particular device/ phone. Whenever we need some change, we can change the value in that particular file.
public static void main(String[] args) throws MalformedURLException {
// Step01:- Set Desired Capabilities
DesiredCapabilities dc = new DesiredCapabilities();
dc.setCapability("appPackage", "com.android.dialer");
dc.setCapability("appActivity", "com.oneplus.contacts.activities.OPDialtactsActivity");
dc.setCapability("deviceName", "OnePlus 7T Pro");
dc.setCapability("platformName", "Android");
dc.setCapability("automationName", "UiAutomator2");
dc.setCapability("noReset", true);
// Step02:- Create the driver and hit the appium server
AndroidDriver<WebElement> driver = new AndroidDriver<WebElement>(new URL("http://0.0.0.0:4723/wd/hub"), dc);
From the above sample code we infer that we can store all the values of the capabilities in a property file and can use them. Whenever we want to execute the tests against another device we can change the values in the property file so that the tests will target the new device/phone which is specified in the property file.
Test runner annotations usage for sequential and timely executionIn order to run Appium test cases, we need the Appium server up and running, test code should be loaded and the driver object should be loaded with all desired capabilities. After the successful execution, and after getting the final report, we need to close the server.
Hence we would recommend to use the TestNG annotations wisely.
Eg: @BeforeSuite- start the apium server in here @BeforeSuite- configure the driver (Android driver/ IOS driver) @Before method – open tha app/ browser @Test- run the actual test scenario @AfterMethod- close the app or browser @ AfterSuite – close the server.
Related Blogs
Conclusion
Thank you very much for sparing your valuable time in reading this blog article, we hope you find this Appium tutorial insightful and discerning, We conclude this with much contentment and with great hope that this blog article will help an individual to understand how to design a good framework for a mobile test automation using Appium.
Comments(0)