When are system properties registered and are JUnit properties supported?

[mgroth0]

I'm trying to understand how this plugin registers system properties, and whether or not we should expect them to work all scenarios or only some.

My understanding based on what I have found is that we can set system properties with the "systemProperties" runner argument:

https://github.com/mannodermaus/android-junit5/wiki/Conditional-Test-Execution#enabledifsystempropertydisabledifsystemproperty-

and that they are then registered by the AndroidJUnit5 class :

android-junit5/instrumentation/runner/src/main/kotlin/de/mannodermaus/junit5/internal/runners/AndroidJUnit5.kt

Line 57 in 38ef72c

private fun registerSystemProperties() {

However, after see the documentation and the implemtation, I have a few questions:

1. When exactly are they registered? I am not too familiar with the JUnit framework under the hood, so I do not know when we should expect this registerSystemProperties function to run. If there is a static initializer or some other operation that runs early in the JUnit lifecycle that reads a system property, I am not sure if registerSystemProperties would have run yet or not. I am also wondering about possible static initializers from other dependencies, not just JUnit.

2. More specifically, are JUnit system properties such as "junit.jupiter.execution.parallel.enabled" supported? My concern is that JUnit might read this property early in its initialization process before registerSystemProperties.

To be clear, this question is not based on any observed behavior. I haven't checked for myself anything related to system properties yet, because I'm not sure what I should expect.

[mannodermaus]

As you point out, you can provide Java system properties to the Android instrumentation via a runner argument. The most common applications for this would be to either add them to your build script file (i.e. in build.gradle.kts), or to apply them along with the command that starts the instrumentation tests (i.e. via adb shell am instrument... or ./gradlew connectedAndroidTest).

1. The system properties are registered by the AndroidJUnit5 runner before execution of a test class with JUnit 5 tests starts. Think of it this way: The Android instrumentation throws a class at this runner, and the runner determines if there are any relevant tests inside of it. If yes, then they are executed, and just before that point, some user configuration is initialized – this includes any potential system properties.
2. Parallel test execution is supported by instrumentation tests, but I'm not advertising it broadly yet as it is quite experimental. The Android instrumentation is very much based on a single-threaded execution model and I had to go to great lengths to try and make parallel execution work. This is especially true for UI tests, which cannot be run in parallel (my library checks for this and skips parallelism for these tests, if necessary). In other words, you can go ahead and provide junit.jupiter.execution.parallel.enabled to the instrumentation runner and it will execute your tests in parallel.

[mgroth0]

Thank you for the answer!

I'm mostly curious about the timing of when system properties are applied. Wouldn't it be nice if we had a way to apply system properties before the "JVM"(or Dalvik) runtime starts? Like when we start a normal java process with -D options.

To be honest, I'm not very familiar/comfortable with how the android runtime works. I just found this answer here which says:

System properties are read once when the root VM (Zygote) is started, which in turn spawns other Dalvik VMs like that of your application. That means you cannot set system properties on the fly.

As I have been learning Android (with a java background), I have often been confused about how isolated android apps from eachother. Recently I've read many things that have suggested that each android app is its own separate process, but this SO comment seems to suggest otherwise.

This is probably way outside the scope of this repository, but do you happen to have any insight or advice on these topics?

[mannodermaus]

The support for system properties in android-junit5 is done mostly to bridge the gap between some of the conditional annotations in JUnit 5 and the Android ecosystem. That's why we can afford to apply them after Dalvik/ART have already started. When using Gradle, you can provide system properties with -D to your tasks, but these properties remain fixed to the local environment and wouldn't get sent to a connected Android phone, esp. not before an app process is launched by Zygote. Rooting your device might be a possible way, but I have no experience with that.

In all honesty, system properties are not a common occurrence in Android development and are only rarely used. 😅 I don't have much more insight into the topic than what I've already given, and I agree that it would be outside the scope of this repo to go much further. However, I confirm that yes, each Android app is its own isolated process, with some rigid ways to share data across process boundaries (e.g. with content providers or the intent system). For more info, I'd like to redirect you to the Android page on the topic.