It's tough to be a quality assurance engineer working for a mobile development company, because in a segment with tough competition, that company must offer top-quality products, dashing speed and attractive, competitive prices to stay afloat. At Azoft we provide quality assurance, but tight deadlines and limited budgets put severe restrictions on our QA team. That's why we are constantly developing new automated testing tools and methods to reduce costs, while preserving top-notch standards. That's why 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.
- 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.