How to Use Imagrium for iOS and Android Mobile App Testing
It’s tough to do a mobile app testing in a software development company. When the competition is high, a company must not only offer top-quality services, but also do it fast and at a competitive price. At Azoft we provide quality assurance, but tight deadlines and limited budgets put restrictions on our QA team. We are constantly developing new automated testing tools and methods to reduce costs, while preserving top-notch standards. To streamline our internal mobile app testing we created Imagrium.
Imagrium is a cross-platform mobile application testing framework written in Jython and based on image recognition technology. It is distributed under an MIT License, and you can use the framework as a template for your own automated software testing.
Mobile App Testing Stack
- Sikuli — for image processing;
- Jython — for running tests;
- Apache Ant — for running tests and reporting;
- Jenkins — Imagrium can be easily integrated into Jenkins so that developers can run tests and receive reports as they work;
- Genymotion and VirtualBox — for snapshot processing;
- PyDev — a wrapper.
As a well-functioning testing tool, Imagrium must:
- be cross-platform, i.e. have a common API for different mobile OS;
- have resources (in our case images) decoupled from logic and not use images for operations performed by the user (for that reason, we use PageObject patterns);
- allow CI support and code debugging. Imagrium can be easily debugged Eclipse. Moreover, when using Eclipse, the framework can be integrated into Jenkins.
- guarantee that all tests can be run on the same initial state of OS. This is particularly useful when running parallel or selective tests and handing tests that fail.
- fasten OS emulator respond. For snapshot processing, Imagrium uses Genymotion and VirtualBox.
Give Imagrium a try, if you share these principles and are looking for automated testing tools. Here’s how to start.
How to start
Note: The current version of Imagrium runs only under Mac 10.9 and Win 7 ( 64-bit).
To do so, locate the git repo root from the command line and run:
This command launches the OS emulator and takes its snapshot for use for all testing during that session.
The code of an app test falls into two groups: pages and tests. By “test”, we mean a sequence of operations for certain pages, e.g.
authPage = AuthPage.load(AppLauncher.box, self.settings) fbAuthPage = authPage.signUpFb() fbAuthPage.fillEmail(self.settings.get("Facebook", "email")) fbAuthPage.fillPassword(self.settings.get("Facebook", "password")) fbConfirmPage = fbAuthPage.login() LobbyPage = fbConfirmPage.confirm()
Page is a Jython unit representing an app page, screen or activity. It is technically a class with fields and methods to perform for these fields.
The most complex page looks like this:
class FbAuthPage(Page): email = ResourceLoader([Resource.fbEmailFieldiOS, Resource.fbEmailFieldiOS_ru]) password = ResourceLoader([Resource.fbPasswordFieldiOS, Resource.fbPasswordFieldiOS_ru]) actionLogin = ResourceLoader([Resource.fbLoginBtniOS, Resource.fbLoginBtniOS_ru]) def __init__(self, box, settings): super(FbAuthPage, self).__init__(box, settings) self.email = self.box self.password = self.box self.actionLogin = self.box self.settings = settings self.waitPageLoad() self.checkIfLoaded(['email', 'password']) def fillEmail(self, text): self.email.click() self.waitPageLoad() self.inputText(text)
If you are interested, we provide detailed information at GitHub on how to write pages. That information covers the following aspects:
- field definition and localization
- field initialization and check-up
- field attributes and methods
- OS-dependent functions
- page organization
After writing pages for a new platform or density, you can run the same test with different configurations on various platforms.