Appium Framework Design Creation

In the previous article of this Appium tutorial series, we have seen Mobile Automation Gestures. Now in this article, we will see Appium Framework Design Creation.

Many a time in an interview, when the interviewer asks the question to explain the automation framework, we tend to get confused about where do we start explaining the same?

Of course, the test automation framework is not something that can be explained in a couple of minutes, but what we need to understand and further make the interviewer understand is how the overall structure was.

I have designed the below framework structure in a very generic way and can be used to comprehend the manner, how any given test automation framework is designed or used.

Consider the IDE as eclipse and the root of the project as the Page Object Model, and it has two main packages,

src/main/java – Package for holding additional parameters that help to build the automation test suite

src/test/java – Package for holding all the test cases

Digging further deeper, the src/main/java package as we can see holds Base class, Config files, excel reader, screenshots (test evidence), Page libraries, Html report folders.

Each of these folders will serve its own purpose as follows:

Base Class: Here we will keep the test base class, which will have the general cases mentioned and scripted. This test base class will then be extended in other or all the test cases using the JAVA OPPs concept of inheritance. This will help in code reusability and also align with the best practices

Config file: This file will store all the configurational data, such as the URL, wait times, etc. Once declared here, the test suite will use the data from here itself. In case of any changes, we won’t be required to change everywhere in the test suite but only at one location that is the config file.

Excel Reader: When testing in reality, we have the test data supplied from an external source. This is always preferred as the test data is subject to change and can largely vary. Hence to maintain the same, the test data has to be supplied through the excel file. However for the automation test suite to read it and apply the test data in the test scripts, there has to be a program written which is nothing but the excel reader file

Screenshots and HTML Reports: As the name suggests, screenshots taken as the test pass or fail evidence needs to be stored at a particular location. This file serves the purpose. Talking about the HTML report folder, every test execution would be accompanied with a test report and the same is stored here.

Page Libraries: As mentioned earlier, the Page Object Model Design would enable us to convert each page of the application into a scripted page library that would hold all the relevant web element locators in it. It would act as the object repository also help us achieve modularity in terms of keeping the business logic and the test cases separate.

Now coming to the src/test/java package, this package would hold up all the test cases with respect to the different page class in the Page libraries folder.

Additional parameters like TestNG, Maven, Log4j, and test output file would support in different ways by providing additional helping hand.

When specifically talking about mobile application automation, we have certain pre-requisites that have to be in place before starting with the development of the automation framework.

Pre-requisites are as follows: