I wonder why I get JUnit4 when running test balloo...

# testballoon

[Eugen Martynov]

I wonder why I get JUnit4 when running test balloon in the Android library module

[Eugen Martynov]

I mean these are same as plain jvm tests. So I hoped that uses just test ballon infra to run tests.

[Oliver.O]

It is TestBalloon running the tests. But who starts it? Who relays test events to Gradle? Who sets up the infra for instrumented tests?

[Eugen Martynov]

I'm not sure I understood the reply. Does plain kotlin jvm module use junit under the hood?

[Eugen Martynov]

Sorry for the newbie questions - looks like yes github.com/infix-de/testBalloon/blob/…/TestBalloonJUnitPlatformTestEngine.kt

[Eugen Martynov]

Should start with reading documentation folder in project. Pausing all questions till finishing that.

[Oliver.O]

So we have these two underlying APIs in "JVM-like" testing: JUnit 4, which is less capable in general, but the best supported API on the Android platforn, and JUnit Platform, which is more capable in general, but lacking in Android integration. For TestBalloon itself, the capability differences between these two to not matter a lot, but the integration quality does.

Maybe it boils down to the following questions:
1. In "plain JVM" cases, why does it matter whether TestBalloon uses JUnit 4 or JUnit Platform under the hood?
2. Isn't that mostly just an implementation detail?
3. Why would one use TestBalloon on top of JUnit Platform instead of JUnit 4 in an Android environment?

[Eugen Martynov]

I'm not sure I understood point 3. My answer for question 1 - "it doesn't not matter" if no other test infra affected like parallelisation (not sure what else). The Junit4 question arose since I thought test ballon has own running infrastructure that unlocked better parallelisation or other functionality. The answer for question 2 - "yes" and again shouldn't care. The message around junit5 is successor of junit4 might bring to usual people idea junit4 shouldn't be used in favour of junit5.

[Oliver.O]

if no other test infra affected like parallelisation

Actually, this is not affected by using JUnit 4 vs JUnit Platfom.

TestBalloon is fully in control how it runs its tests, and is capable of parallelization on both, JUnit 4 and JUnit Platform. At test run time, these APIs are basically used to forward test events.

However, the Android test infra hooks into these test events and expects single-threaded sequential execution. Instrumented tests, for example, would just crash silently with parallel (or even concurrent) event reporting. And UI stuff like activities also expects strictly sequential execution. These are limitations of the underlying Android test infra that can be overcome only if Google decides to change them.

Beyond that, yes, JUnit 5 does have some advantage over JUnit 4, but none of them comes close to what a Kotlin-first test framework like TestBalloon can offer. And if that happens to work without rewriting the entire underlying test infra on Android, you get the best of all worlds. Even without parallelization, you have easy parameterization, less code to write and review and a much better Kotlin-first DX.

And if you want parallelization: You can put parallelizable code and tests in a JVM-only module where it is clearly independent from Android requirements and safe to run in parallel, but can still be used in Android-specific modules.

[Eugen Martynov]

Thank you, that is exactly what I'm looking for! Sorry I was not clear with my starting message - I was confused/not experienced with seeing "junit4" in the output.

[Oliver.O]

That's fine! I understand that it can be confusing because of all the underlying legacy infra.