Junit5: Allow Gradle plugin to support Android projects

[mannodermaus]

At the moment, the junit-gradle plugin doesn't work on Android environments, since the handling of SourceSet containers and the general notion of the runtime classpath differ from plain Java, both syntactically and functionally. For instance, there is no testRuntime configuration in Android projects, and the testClasses task is missing as well.

I have started working on Android support in my fork, however that isn't done yet. Maybe one of you guys has already had Android support on their radar all along?

Thanks!

[jlink]

At the time JUnit5's current design was conceived (Oct 2015) it looked like
Android wouldn't be on Java 8 for another couple of years. So we considered
Android support to be out of reach for some time and didn't bother.

Now that prospects have changed, it might be time to think about Android
again...

2016-03-15 11:21 GMT+01:00 Marcel Schnelle [email protected]:

At the moment, the junit-gradle plugin doesn't work on Android
environments, since the handling of SourceSet containers and the general
notion of the runtime classpath differ from plain Java, both
syntactically and functionally. For instance, there is no testRuntime
configuration
https://github.com/junit-team/junit5/blob/master/junit-gradle/src/main/groovy/org/junit/gen5/gradle/JUnit5Plugin.groovy#L28
in Android projects, and the testClasses task
https://github.com/junit-team/junit5/blob/master/junit-gradle/src/main/groovy/org/junit/gen5/gradle/JUnit5Plugin.groovy#L66
is missing as well.

I have started working on Android support in my fork
https://github.com/aurae/junit5/blob/gradle-android/junit-gradle/src/main/groovy/org/junit/gen5/gradle/JUnit5Plugin.groovy,
however that isn't done yet. Maybe one of you guys has already had Android
support on their radar all along?

Thanks!

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/junit-team/junit5/issues/204

[mannodermaus]

Thanks for your reply! The greatest thing about JUnit tests for Android developers has always been the fact that they are decoupled from the limitations that Android imposes on developers (mainly related to being bound to Java 6, and in parts, Java 7). This allows us to enforce TDD by not having to wait around for instrumentation tests to deploy to devices etc. That being said, Android getting Java 8 with the N release shouldn't even necessarily be the main reason that JUnit 5 should come to the platform, since a lot of devs have been using Java 8 as their internal foundation for quite some time now!

[jlink]

Maybe you can add a few details to the points you mention in the issue description, so that we can estimate the effort and schedule it in one of the next releases. I'm quite sure, though, that it won't be part of https://github.com/junit-team/junit5/milestones/5.0%20M1 :-/

[mannodermaus]

I have made some good progress already, so that all relevant JUnit5 tasks are being initialized properly, and the most basic of tests are already picked up correctly. However, I am somewhat running into a wall when trying to set up the Android equivalent of the runtime classpath.

Some background info on the way that the Android environment deals with its source sets: In Android, an application's classpath isn't tied to the main and test source sets directly, since you can have multiple flavors of the same application with similar features (for instance, you can deploy both a "free" and "paid" version of your app, with the former having included advertisements etc). On top of that, there are so-called build types that may provide further variation (for instance, you can have a "debug" app for development, and a "release" build with integrated crash reporting tools). Combined, these parameters define an application's variants:

variants = flavors + build types

For an app with two flavors (free and paid) and two build types each (debug and release), the following variants are created:

freeRelease
paidDebug
paidRelease

Each variant may include its own dependencies and therefore shape the compilation classpath in a certain way. This needs to be reflected by JUnit5's Gradle plugin (you can see here that I iterate over all available variants and add the corresponding JUnit5 task to them)! On top of that, the "testRuntime" configuration doesn't exist in the Android plugin; the next best thing would be the "testApk" configuration, which describes dependencies that aren't being added to the compilation classpath, and are instead only packaged (e.g. into the final APK file). This could be used to add the engine and runner dependencies instead.

As I've mentioned, at this point, really the only difficulty I'm facing is setting up the correct classpaths for each variant, since the runner fails with a NoClassDefFoundError upon starting the JUnit test discovery, more precisely when it hits a class from the Android framework that doesn't exist, because we're on the JVM as opposed to a real device. I'm pinging Xavier from the Android Tools team (@ducrohet), since he may have some insight on how this could be mended.

[marcphilipp]

How do you add a testing-related library, e.g. a mocking library such as Mockito, to your classpath for testing?

[mannodermaus]

You'd generally use testCompile for all testing-related affairs, including Mockito, AssertJ and the like.

[marcphilipp]

Maybe you could try that as an intermediate solution/workaround?

[mannodermaus]

I finally got it to work by mimicking the way the official Android unit test support sets up its classpath. Android Studio doesn't pick up the dependencies declared within the plugin correctly yet, so that they need to be redeclared in the app's build.gradle, but I was able to get it to run the JUnit5 tests - the key to success was including a mocked-out version of the android.jar file, which is created by the plugin so that the runtime classpath has references to Android framework classes (even though they don't actually do anything when called).

[ducrohet]

+Michal who's implemented the unit test support.
On Mar 17, 2016 10:13 PM, "Marcel Schnelle" [email protected]
wrote:

I finally got it to work by mimicking the way the official Android unit
test support sets up its classpath
https://android.googlesource.com/platform/tools/base/+/8db68636c1d110f92662cf4023b2ad22147daf75/build-system/gradle-core/src/main/groovy/com/android/build/gradle/tasks/factory/UnitTestConfigAction.java#84.
Android Studio doesn't pick up the dependencies declared within the plugin
correctly yet, so that they need to be redeclared in the app's
build.gradle, but I was able to get it to run the JUnit5 tests - the key
to success was including a mocked-out version of the android.jar file,
which is created by the plugin so that the runtime classpath has references
to Android framework classes (even though they don't actually do anything
when called).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/junit-team/junit5/issues/204#issuecomment-197873843

[Adambl4]

Any progress on this issue?

[marcphilipp]

Has any of you tried the proposed pull request #213? I think the correct way forward would be to get support for JUnit 5 into core Gradle. However, we don't currently have the resources to work on that. :-/

[mannodermaus]

Given the rapid development of the platform over the past months, the contents of my pull request seem to be gravely outdated at this point. I will try to allocate some time to revise the work and bring it up-to-date with the M2 release.

[mannodermaus]

I have just submitted a new PR with the same changeset based on the current state of the project: #499

[sbrannen]

FYI: the Android JUnit Platform plugin for Gradle by @aurae has just been updated to support JUnit 5.0 M6.

https://github.com/aurae/android-junit5

[SarthakM9]

Hello all, is there any way to run JUnit5 in Instrumented tests in Android?

[marcphilipp]

@SarthakM9 I think you have a better chance of getting a helpful answer at https://github.com/aurae/android-junit5.

[marcphilipp]

I'm closing this issue since we our Gradle plugin is an interim solution until core Gradle support is available. Feel free to let Gradle know that you need it over at https://github.com/gradle/gradle/issues/1037. 😉