Member since 4 years
These days we find most of the apps are being developed across different platform, iOS, android, windows and to keep the user base which uses web, mobile web and websites.
When apps are being developed for cross domains, most of the functionality provided by the app is very similar, varying thing is PLATFORM.
In rapid development cycle, where there are tools which allows you to write once and reuse across multiple platforms, makes development very faster.
But at the same time, if we have different automation suite for different platforms, it becomes very difficult to keep a pace with ongoing functionality.
This is the exact problem we faced, and the solution we came up with is "One Page to test them all! -A cross platform mobile automation framework! "
Page Object Model
Well, Page Object Model was again a natural fit for this framework. Most implementations of POM recommend different POMs for each platform. But we wanted to have a single Page Object Model for all the 3 platforms to ensure maximum code reuse and reduce overall time spent in adding new automation.
Single Page Object Model across platforms
This was complicated because we had native screens as well as webview screens and so it was not possible to use the same Page Object. To solve this, we introduced abstractions for the elements on the screen and encapsulated the respective native driver implementations.
This also allowed us to implement common automation tasks in one place for e.g waiting for new pages to load, so that this code is not repeated across multiple step definitions and platforms. This helped us move to thinking in higher domain level concepts than in terms of low level UI interactions.
So, in summary, we write our tests for one platform and run them for all with an abstraction layer in place.
Problem we faced
Our current project is a mobile app for iOS, Android and Mobile web, which is a mixture of pure native screens and webviews. Each platform has its own tools for UI automation like Calabash for iOS/Android and Watir-Webdriver for Mobile Web. But we wanted to create a generic automation framework which could support each of the above UI automation frameworks but still reuse as much code as possible and avoid duplicating code between them.
Page Object Model
Page Object Model was again a natural fit for this framework. Most implementations of POM recommend different POMs for each platform. But we wanted to have a single Page Object Model for all the 3 platforms to ensure maximum code reuse and reduce overall time spent in adding new automation.
Single Page Object Model across platforms
This was complicated because we had native screens as well as webview screens and so it was not possible to use the same Page Object. To solve this, we introduced abstractions for the elements on the screen and encapsulated the respective native driver implementations.
This also allowed us to implement common automation tasks in one place for e.g waiting for new pages to load, so that this code is not repeated across multiple step definitions and platforms. This helped us move to thinking in higher domain level concepts than in terms of low level UI interactions.
