Develop Reference

Best practices for testing multi module android app

I have an application with 4 different modules. Network layer is separated in different module and I created a fake repository for unit testing in it.
The problem is that I cannot access that fake repository in my main module test classes (for creating test classes for viewmodels). I tried different solutions from google and none of them are working.
If I use something like this in gradle
testImplementation(project(":data"))
Test classes are still not visible.
My question is what are the best practices when writing tests for multi module android application? Is good practice to create one module for test and put everything related to testing from every module in that one? Or is there a way to make test classes from other modules visible in my main module?

How can I unit test Android resources in feature modules?

My app is using feature modules. One of the feature modules declares a bunch of strings in an xml resource, and then accesses them from my kotlin code: e.g. getString(R.string.dialog_title). I want to run Junit tests to prove that the correct string content is retrieved.
The Robolectric documentation page suggests using the function getApplicationContext<MyApplication>(). However, you don't have access to the Application when unit testing a feature module. I guess that's because feature modules exist separately to the application?
Any help appreciated. :)

Robolectric will slow your unit tests a bit. You can just mock context object and then do something like: when(context.getString(any()).thenReturn('any/empty string')

Gradle task to only execute uiTests

I've got this Android, with the default Gradle-tasks. In the Android-project, there is a androidTest package, containing integrationTests and uiTests. I have also two Kotlin classes containing a suite of test classes to be called.
However, ./gradlew connectedAndroidTest runs both integrationTests and uiTests, I want to separate this. I came up with multiple solutions:
Android Studio's run configurations. However, this isn't checked into VCS, therefore we have no access on our Jenkins build server.
Add Gradle tasks in the Groovy language, however, it's not encouraged to call another gradle task in a new task.
So I'm looking for a way to only test either integrationTests or uiTests. How can I do this?

I'm going to give you a cheap and cheerful answer now. Maybe someone else will be able to provide a fuller one.
Since all the tests appear to be part of the same source set, you need to distinguish between them some other way. The most appropriate solution is whatever mechanism your testing library has for grouping, which you can then utilise from Gradle.
Alternatively, use something like a naming convention to distinguish between UI tests and integration tests.
What you do then depends on how you want the build to deal with these different categories. The main options include:
Using test filtering from the command line — via the --tests option — to run just integration or UI tests. Note that filtering only works via class name, so you'd have to go with the naming convention approach.
Configure the appropriate Test task — is that connectedAndroidTest? — so that if you set a particular project property it will run either the integration tests or the UI tests based on the value of that project property. This involves using an if condition in the configuration. This approach works with both filtering and grouping.
Add two extra Test tasks, one that executes the integration tests and one that executes the UI tests. You would leave connectedAndroidTest untouched. This is my preferred approach, but requires a bit more code than the others.
This answer is missing a lot of detail on how to implement those solutions, but I'm afraid filling that detail out is too time-consuming for me right now. As I said, hopefully someone will come along with a fuller answer.

Android Junit Testing vs. Normal Junit Testing

I'm taking over an android project and I wish to introduce unit tests to the project, to help avoid possible regressions.
For normal java projects, I have two source folders: src and test. The src source folder contains all of my source files and my test source folder contains all of my unit tests, which I believe is pretty standard for keeping test separate from the source, so you don't have to ship with them.
I've been doing some reading online and the approach with android apps looks to be a little bit different. Several examples talk about setting up a 2nd project for an android test project and then referencing the android project.
I wish to confirm a few things:
Is having a 2nd project for the testing the appropriate thing to do when it comes to testing android projects or am I just finding bad examples?
Should all unit tests be android unit tests? E.g. Yes they should all be, or no I should mix between android unit tests and junit because junits have less overhead.
What additional benefits do android unit tests give over junit tests? E.g. Handles to the emulator, etc.

Is having a 2nd project for the testing the appropriate thing to do
when it comes to testing android projects or am I just finding bad
examples?
Yes, it's typical to have a separate "test project" for testing Android specific code. http://developer.android.com/tools/testing/testing_android.html
Should all unit tests be android unit tests? E.g. Yes they should all
be, or no I should mix between android unit tests and junit because
junits have less overhead.
You'll usually have a mix because you can't test Android specific code on a standard JVM with regular ole' JUnit (not without some helper libraries, more on that in a moment).
In practice I've found that it makes sense to divide your application into plain JVM components and Android portions. For instance, if you need to communicate with a REST API you can have a separate component that does only this and which is plain Java. These types of components can easily be tested with standard JUnit. This type of architecture also leads to a clearer separation of responsibility and often and easier to understand and maintain design as well. (Such components can be included in your Android app as regular JARs.)
What additional benefits do android unit tests give over junit tests?
E.g. Handles to the emulator, etc.
Android testing can be slow and painful because a full Android test runs the Android stack in an emulator (or on a device). Android tests are however necessary for testing the parts of your application that are Android specific, such as Context/Activity/Service and so on.
Because of the cumbersome and slow nature of native Android tests several frameworks have been created that mock or stub parts of the SDK and take different approaches to help. You may want to look into Robolectric and Robotium, for instance. (These each have their own pros and cons.)

Run junit test cases from multiple class files (Robotium)

I am actually using Robotium testing framework for Android, but I believe it's based on JUnit. I am new to JUnit as well as TDD.
I want to create different test class files based on features, like "LoginTest.java", "EditProfileTest.java", and each file contains some test cases for that feature.
The question is that, when I run it within Eclipse by clicking F11, only one file will run. I don't want to put all test cases in a single file. Is there a way to run multiple files at once? Or other ways to solve this problem.

You can either create a JUnit Test Suite, or if you just want to run all tests in all the classes in a particular java package you can do that in Eclipse by right clicking on the package, choosing Run As, and Android JUnit Test.