Maximizing Efficiency in Android Development with CircleCi (2023)
Test efficiently and effectively
A brief tutorial on CircleCi service for automated testing in Android projects, including the setup process and various modules for development: maximizing efficiency and mastering the tool for efficient and reliable testing.
The CircleSample on Android Projects uses the CircleCi Service. To use this service, you need to create an account and register on CircleCi.
The Basic Module involves registering your Android/Gradle project on CircleCi. In this tutorial, we will use a Github Repository and CircleCi will need a yml file to connect with gradle, which should be placed in the ‘.circleci/’ directory.
> ./circleci/config.yml
version: 2
jobs:
build:
working_directory: ~/code
docker:
- image: circleci/android:api-25-alpha
environment:
JVM_OPTS: -Xmx3200m
steps:
- checkout
- restore_cache:
key: jars-{{ checksum "build.gradle" }}-{{ checksum "app/build.gradle" }}
- run:
name: Chmod permissions #if permission for Gradlew Dependencies fail, use this.
command: sudo chmod +x ./gradlew
- run:
name: Download Dependencies
command: ./gradlew androidDependencies
- save_cache:
paths:
- ~/.gradle
key: jars-{{ checksum "build.gradle" }}-{{ checksum "app/build.gradle" }}
- run:
name: Run Tests
command: ./gradlew lint test
- store_artifacts:
path: app/build/reports
destination: reports
- store_test_results:
path: app/build/test-results
In the configuration of Github, it is important to ensure that writing permissions are enabled for immediate committing in the original branch.
To create a dynamic test unit, you can throw an error assert on a Java Class located in the test directory.
Write an error comment in the commit, which will be visible on the Repository and CircleCi.
Create and push a new branch with this commit.
When pushed to the remote repository, you can view the CircleCi dashboard, which will show the status of all tests in real-time 'running'
When the tests are finished, the dashboard will display one of two statuses: failed or success. In case of failure, an issue will be shown.
If the problem is found, the test unit cases can be corroborated, and a new commit and push can be made. This will automatically update on the CircleCi dashboard.
Great CircleCi runs all test cases and does not find any issues, but finds a previous test case that had failed and has already been corrected.
The CircleCi dashboard displays the following:
- NOT RUN: A test case that has not run yet, and CircleCi needs permissions to run the testing cases.
- SUCCESS: All test cases run successfully.
- FAILED: Test cases that did not run well.
- FIXED: Previous test cases that had failed and have already been corrected.
In the Intermediate Module, we will see the real usefulness of the Circleci tool. Let’s suppose that in our team development, we want to assure that the main branch of our repository always has a stable version, where everything developed has been proved correctly.
On Github, go to configure and edit branch permissions, leave a blank space in the ‘write access’ input, and uncheck or revoke all permissions for direct changes, and enable pull request tasks for everyone.
Create a new testing case called ‘serviceModule’, in this case, we will use the mockito library.
Make the respective commit
Try to send our changes to the remote ‘origin’, the repository will reject the changes because it does not have permissions.
To solve this, create a new branch from our worked branch. If you are using Android Studio, in the ‘Push Commits’ window, write the name for a new branch called ‘BranchServiceTest’.
When pushed, the branch will work because we only disabled the changes on the master branch or direct push.
On the CircleCi dashboard, a new record with NOT RUN label and the last commit, CircleCi detected new changes on the repository but does not have permissions.
On Github, we look for the three changes that had a new test_branch branch, built from AndroidStudio.
Suppose a person in charge of the changes, who creates the new branch needs to merge on the remote origin, the person creates a pull request.
In the details, put a message for the respective merge request and indicate close branch when resolved conflicts.
On our project Pull Request display, a new request will be shown.
On CircleCi dashboard, a new record will be added when all tests are run and passed. The record status will change. In our case, it will be ‘success’.
On the screen display, we can visualize a counter of executed tests. In our case, it will not detect any issues with other test cases that have been modified, it will only execute our test ‘serviceModule’ of the class ModuleTest.
When the administrator confirms the new implementation, they can proceed to merge, ensuring a high level of code reliability at all times.
Since we can estimate the tool Circleci, it allows us to have great usefulness for the management and control of the versioning of automated test cases (proofs), allowing to diversify the tasks between the collaborators of the project where they need to test.
In the Advance module, the CircleCi dashboard will show the result:
We can view the record in detail of the testing, step by step displaying all the commands that we have written in the yml file:
On the CircleCi yml file, check the ‘Chmod permissions’ as it is common for beginners using this tool to encounter problems due to the fact that the CircleCi server requires specific permissions:
...
jobs: ...
build: ...
steps: ...
- run: ...
command: sudo chmod +x ./gradlew
...As you can see, the Circleci tool supports gradle flavors, in this project, I am using the ‘SonarQube’ flavor to later connect it to a database of test cases if required by the organization.
Thank you for being here, please comment down your views, if any mistakes found the article will be updated
