Test automation for Rocket.Chat Android Repo

1. How to successfully run ui-test on circleci

In order to run ui tests for every code change, I have created a new job in our present workflow which will set up the emulator and run the UI tests on it. The tests are running fine locally (real devices/emulator), but having some memory issues when running on circleci.

I have tried all the solutions mentioned online but nothing is working in our case. I had tried around 60+ different memory combinations but again the build is red.
I have also set up the circleci locally on my Linux machine and to the wonder, the build is running fine. Maybe the reason is that it is having 8gb ram and the circleci provides us 4gb of memory on FOSS plan. I have also made the fellow developers aware of the issue but again we have no improvement on it. It will be great if you can suggest some way out or any other option we can have for this task. I am looking for the views of the team what should be done in this case.

The error which I am facing is:

Compilation with Kotlin compile daemon was not successful java.rmi.UnmarshalException: Error unmarshaling return header; nested exception is: java.io.EOFException

Unable to clear jar cache after compilation, maybe daemon is already down: java.rmi.ConnectException: Connection refused to host: 127.0.0.1; nested exception is: java.net.ConnectException: Connection refused (Connection refused) Could not connect to kotlin daemon. Using fallback strategy.

Task :app:compilePlayDebugAndroidTestKotlin FAILED

I tried to search for a fix online and got to know that I am not alone, everyone else who tries the similar task is facing this issue

Official Issue trackers

• The issue is already reported at official CircleCI issue tracker here
• For the above post they have suggested that updating to kotlin 1.2.20 has solved for them but we are already using kotlin 1.3.31 and still facing this issue.
• A similar issue is already reported at JetBrains issue tracker here
• The same issue is also mentioned at one more place at circleci here They are suggesting a memory combination with some code change in gradle.build the changes are added and the combination is also tried but they doesn't work.

StackOverflow

• Solution 1 This answer suggests a workaround disable the Gradle daemon for the build, turning off incremental compilation. I have tried this but it doesn't work.
• Solution 2 This issue is similar to our issue and suggests some memory changes tried this but nothing new happens.
• Apart from the above-mentioned solutions, I have also tried various others but it does not work. I even asked a question of my own describing our situation here Someone suggested that he solved this problem on his local machine by increasing the memory.

After trying all the possible solution and even asking the question on StackOverflow and getting a similar reply, I personally lead to a conclusion that we can run the UI test with 4 GB on circleci. This can be the reason why there are no or very few open source project which is actually running the espresso UI tests on circleci. Though I am still eager to know from others that if there is any possibility that we can run the UI test within 4 GB limit.

Since the build is not successful online so the coverage reports for the UI tests are also not generated by codecov. So for that, I have created a static site in order to view the reports. It will help in tracking the progress of the project for now. We can switch to codecov reports back once the ui test build become green.
Site: coverage reports

2. How to test private methods

In our presenters we are having three types of methods:

• Public Coroutines methods
• Private methods which are used in coroutines methods
• Public methods which are not using coroutines

We have decided to not to test the coroutines method as the current codebase doesn't support it and require some major refactoring to be done for that. I have already created unit tests for the public methods which are not using coroutines. So now the only problem left is how to test the private methods which are used in coroutine methods.

For this, I have introduced three approaches:

1. To copy the private methods to the test class and then tests them from there.
2. To create a new public method for each class which will contain all the private methods of that class and then tests the private methods using it like this.

    fun enablePrivateMethodsForTesting(currentServer: String, userName: String, token: Token) {
        setupConnectionInfo(currentServer)
        saveAccount(userName)
        saveToken(token)
    }

    @Test
    fun check_account_is_saved(){
        loginPresenter.enablePrivateMethodsForTesting(currentServer, userName, token)
        verify(saveAccountInteractor).save(account)
    }

3. To change the access specifier of private methods and make them public.

Each way has its own impact on code coverage. I am looking for the views of the team on it so that we can choose the best way out of it and also any other option if have missed.