Testing has always been a trending topic in the world of Android. It becomes a time consuming task in large android projects where multiple developers are working together, maintaining the code quality and resolving bugs; which is a very difficult task.
This is a very serious issue in the open source projects where multiple developers from different environment and different level of expertise contribute to a single code base. Everyone is not the perfect and someone can commit changes that break the application code and we should have something that can alert us if someone is doing something wrong as soon as possible.
It would be great if we can find out that whether the code we are going to push onto our master branch of repository contains any possible bugs that can break the system. Here, continuous integration comes into play.
What is Continuous Integration?
Continuous Integration (CI) is a development practice that requires developers to integrate code into a shared repository several times a day. Each check-in is then verified by an automated build, allowing teams to detect problems early.
In simple words, each time you commit and push your code to the remote repository, continuous integration will check if everything is working correctly in the code before you merge it into your master (assuming you are using git for version control).
With continuous integration, you can:
- Automated build process. Every commit/push to a git repo will automatically trigger a new build.
- Find out Android Lint errors.
- Coding styles to ensure that the new code is matching the code format that your team has decided.
- Get the code coverage percentage. This will be really helpful to figure out if any part of the code is remaining to test.
- Run Unit tests located on your /test directory of project.
- Run Instrumentation tests located in your /androidTest project.
How to configure Continuous Integration?
- An account on GitHub. I believe nowadays every developer has it.
- An account in Travis CI. If you don’t have it yet you can create it from here.
Let’s start with the integration. For the demo purpose, I am going to use API 25 as the targeted Android version in our Gradle and we are going to test our build on API 21 and API 19.
We have skipped the description of some lines as we don’t want to make this article too long and boring. We will concentrate more on the lines which are more important and difficult to understand.
Step-1 : Creating .yml file
First, create a .travis.yml file into your project’s root directory. This file will contain the configuration script for the automated build testing.
That’s it. You are ready to push your commit with .travis.yml file.
Run your first build:
As soon as you push the commit to your GitHub repository, Travis will start building the project automatically. You can see the past build history by going to the “Build history” tab.
You can see your build status (whether it is running, passed or failed) right behind your GitHub repository commits list.
At this stage, if your build fails, try to find out what went wrong. You can find answers on how to fix those bugs on StackOverflow or paste your error in the comments below. We will try our best to resolve those the errors.
Here is one sample project to help you:
You can also find the test project that we used for the demonstration purpose in this tutorial in the below link. Go ahead and take a look into it.
This is an sample application which validates email address you entered in edit text. Here, we integrated Travis CI and CodeCov using Jacoco. You can see all the build statuses in Travis CI from here. If you want to see the latest code coverage report for the project, you can find it over here. This will give you an idea of how code coverage report looks like.
Continuous Integration (CI) is one of the good practice while developing the code. This lets you and your team concentrate on development and reduces the efforts required for maintaining the code. By outsourcing the maintenance of your test infrastructure, you can remove a whole bunch of work from your engineering team that can then be used to build your product. On another hand, code coverage gives you better idea of the amount of code remaining to test and inspires your team to write better test cases. As an overall effect, they both together help you and your team to develop robust product and allows you to deploy your code with confidence.