IssueTracker

This is a good idea and definitely worth investigating.

I think there's something to be said about what scope these coroutines would run in, but it should be possible to pass it back from adapter internally.

Thanks for the suggestion!

Thanks for the feedback. Currently there are no plans to support JUnit5 in Android Studio.

Intellij already supports JUnit5. I think this is relevant to AGP and Android's UI testing toolchain.

By the way, JUnit 5 works well with unit tests. The only necessay implementation steps are adding this into the modules's build.gradle:

• Enabling junit platform
  tasks.withType(Test) { useJUnitPlatform()}
• Adding Junit dependency
  dependencies { implementation("org.junit.jupiter:junit-jupiter:5.7.2") }

Related Stack Overflow post: JUnit 5 for Android testing

I hear the following sentence at almost every Google I/O: "We listen to our developers!". Well, I would really like Google to listen to us on this one.

cross linking with github: https://github.com/android/android-test/issues/224

+1

The ideal scenario, if possible, would be to have something, that doesn't depend on specific testing library, like JUnit in this case.

Hey there, just checking if there has been any updates? Or projected timeline?

We understand that many of you in the Android developer community have been asking for JUnit 5 support when running instrumented tests against your Android projects. We appreciate your passion for staying at the forefront of testing practices and incorporating the latest tools into your development workflow.

The desire to leverage JUnit5's enhanced features and capabilities for Android instrumentation testing is entirely understandable. Therefore, we want to be transparent about the current challenges that prevent us from fully supporting JUnit5 for Android instrumentation tests at this time.

The Roadblocks

The primary hurdle lies in the deep-rooted integration of JUnit4 within the Android testing ecosystem. Our AndroidX Test libraries, Compose Test, and Benchmark libraries all rely heavily on JUnit4's rules and runners. While creating JUnit5-compatible artifacts is technically achievable, there are clear challenges in the process.

To seamlessly support JUnit5, we would need to embark on a substantial undertaking:

1. Revamp the Core: Adapt the existing test runner or build a new one to proficiently discover and execute JUnit5 tests.
2. Parallel APIs: Develop a parallel set of JUnit5 APIs to mirror the functionality of the current JUnit4-based AndroidX Test APIs (e.g., ActivityScenarioRule).
3. Continuous Maintenance: Commit to ongoing maintenance efforts, including adding JUnit5 equivalents for every new API we introduce.
4. Robolectric Migration: Assist in migrating the Robolectric framework to support JUnit5, as it's currently tightly coupled with JUnit4.

On top of those reasons, it is important to note that Google’s own internal testing infrastructure relies heavily on these same libraries. We want to maintain a level of uniformity within Google’s own infrastructure, and migrating to JUnit5 APIs will be a large and separate undertaking.

When we evaluated the benefits of JUnit5 against the effort and resources required to do it, both for internal Google testing infrastructure and for the broader Android developer community, we determined it doesn’t offer a big enough improvement for us to do it.

Looking Ahead

We remain committed to closely monitoring the evolving needs of the Android developer community. As the landscape shifts and resources permit, we'll revisit the feasibility of full JUnit5 support for Android instrumentation tests.

In the meantime, we appreciate your understanding and patience as we navigate these complexities.

No longer addressing technical debt would seem to imply sunsetting Android as far as Google is concerned. I suppose iOS is here to stay, and HarmonyOS will likely be a relevant player in the global market.

hypocrisy is rife...

Here is just a single issue were Google tells ALL developers worldwide to change/add-to their code because Google says-so: Edge-to-edge shouldn't be enable in Target SDK 35 App

I cannot be bothered listing the many-many-many areas where things became "deprecated/replaced" instead of "fixed". i.e. again: all developers to dump certain code and start with an entirely new approach.

I'm sure other people can add similar issues....

Thanks #46 but I'm already contributing to those repos and toolings. In fact, I'd be more than happy to mentor you if you ever want to try doing open source seeing that rwmobi Github profile has zero contributions. Just let me know, ya?

I also wish junit5 was supported for Android development. However I understand the Android team doesn't have infinite capacity. They can't do everything we want. What they said is simply that the upfront effort to support junit5 and than maintain it is too big for the returned value compared to doing something else that is more important for the community.

It is also quite ridiculous to suggest they fork some community effort. Google, like any big company, has very strict standard with code style and quality, they cannot just take a 3rd party software and fork it.

We are developers, 90% of our job is to chose between trade-offs. You should get this is a trade off and stop with the unreasonable requests. I'm glad they finally answered this ticket even if the outcome is not what I was hoping for.

Be thankful Google Android isn't ignoring you all, they are people, they really thought about this and they were forced to say no because at the end of the day the amount of work their team can deliver is finite.

they cannot just take a 3rd party software and fork it.

Robolectric was used to be a community open source project and they merged it into AndroidJUnit4. Dagger is also forked from Square. We have history in the past where taking over open source project has been successful. And Google has recently started embracing open source projects as well, such as deprecating Volley in favor of Retrofit. I don't think code style and quality matters. I do appreciate Google giving us an answer though even though it's not what we want to hear.

Something seems to be going on.

https://android.googlesource.com/platform/tools/base/+/3e27f0cc4
https://android.googlesource.com/platform/tools/base/+/e483250f1