CI role in mobile automation

CI role in mobile automation

Continuous integration server or simply CI, is a very important aspect for every software product. Especially it is important for the mobile projects, as every time you want to test something you need to build your APP. In this article I will explain how CI helps to make Software Engineers lives easier.

Why we need CI

CI has a lot of functions like: running automation/unit/performance tests and getting colourful reports, running deployment jobs and other tasks. But which goal are we, as software engineers, trying to achieve by running tests in CI? The answer is simple: to find bugs and integration errors at the very early stage of the process. Firstly, the earlier the bug is found, the less it costs us. Secondly, these bugs will be fixed quicker and easier, because the developer who has brought the feature in, didn’t forget about this task and still remembers the details about this particular feature.

You may ask, what can stop you from achieving the same without having a CI and running everything locally. Let’s try to identify some advantages of CI:

Not keeping in mind all the deployment settings

When you are working in an agile environment and want to test something in your APP, you will have to think about a lot of stuff like: builds, branches, configurations, profiles and certificates before you can start testing. That’s where CI is very helpful. CI can build everything for you, without you thinking about all of this stuff. This will also exclude the human factor, as one can miss some important parameter, use a wrong branch or install the wrong build.

Reducing the building time

The building time can be significantly reduced due to CI. You will not have to wait until the build is done (in some projects it can take up to 20 minutes), because most probably your build is already in place, as the job was already triggered automatically. And also, it has already taken time for CI to build the APP once and nobody should run the build separately and spend his time again.

Getting earlier builds with the latest code

CI can automatically build the APP on every commit on master, so you will have latest code every time you request the build. In this way you will not care about getting all the changes and build the proper APP again.

Over Nightly builds

One of the big advantages is running tests on the latest master during the night, so when you arrive at work you can analyze the results and file a bug if something was caught. To achieve it, you will also need to get the build from the latest master.

Ideally, having over nightly running integration in place, you can release the APP every day if integration has passed.

Use CI builds for your local runs

Having a build in CI is already very good, but you will still have to download, copy and paste the build manually. What we are doing in our project is asking the user which build he wants to download before the test run. If he chooses the build from master, the script will automatically download the latest successful build and start tests against this build.

Use CI for Pull Requests

One more field, where CI is widely used, is pool requests. You can configure everything in such a way that unit, performance and automation tests are starting automatically when you create a PR. If tests fail, CI will notify the developer about the error and he will be able to commit bug fixes even before PR goes to master.

Creation and maintenance of CI jobs

If you have a lot of jobs you will face the problem that they are hard to maintain. Imagine, that you change an executable file name or a version of Ruby, and you have to go manually through all the jobs and change it. This is not the job you want to do. Instead, you can learn about automated CI jobs creation. You will spend some time on putting everything in the script. But having done so, you can change everything you want in some minutes instead of wasting hours on manual copy/pasting.

Risks and obstacles

CI is a really powerful tool but of course it also brings risks. First of all, CI is another dependency for your project. CI can go down or become unstable at a very important moment, like final automation checks or deploying the release APP. Also, CI means maintenance. Someone will have to take care about all the CI nodes, plugin updates, system updates and etc. This is a risk, that people working on big projects have to take and deal with, as it is impossible to imagine any big project without using the CI.


This was an overview of CI and test automation. I will return with more details in the next articles. Please leave a comment below this article if you are interested in CI or have any questions. I will be glad to receive any proposals or ideas regarding this theme.

3 thoughts on “CI role in mobile automation

  1. You make good points but have you considered the system integration of tests including hardware and operating system conditions? This wouldn’t really apply to mobile web apps but my question revolves around mobile hybrid and mobile native apps. As long as the project team doesn’t only care about unit & integration tests while forgetting about the inter-dependencies at the system level, then I think this is solid approach. But if your project is at the mobile hybrid & native apps, then a strategy in the application of CI. Performance testing is not just about testing the webserver. There needs to be testing at the device level too.

    1. I meant exactly native APPs. We have a CI server with 15+ OSX nodes for iOS and some linux nodes for Android and build there only native APPs. How I mentioned in the article, maintenance of Xcode / OSX / Ruby versions and etc. is not very easy. But with some scripting it becomes simpler. About the mobile devices, I didn’t get the system operation conditions here, as everything will be tested on the phone itself, all that you will have to think about is having Xcode tools for iOS and Java + required Android framework on your CI node. What about interactions with the device, you can do it from the automation and run the automation script on simulator or real device through the CI.
      We’re also trying a new method of running performance tests on devices. Performance tests will be run together with automation scripts. Automation will do gestures and stuff and another tool will measure the performance. And we are planning to run all this also on CI.

      Please let me know if I haven’t answered your question.

Comments are closed.

Comments are closed.
Skip to toolbar