Support for Android pre-API 26 about testparameterinjector HOT 3 CLOSED

Hi Jake!

Just some context: I don't work / never have worked on Android, so I have limited insight into how testing on Android is different from testing server code.

One thing that I have noticed, is that the Android teams almost haven't used TestParamterInjector internally, while hundreds of teams have been using TestParamterInjector for server code. I assumed this was because Anroid tests tend to use custom runners like RobolectricTestRunner. Is the non-Google Android world different enough to make a TestParamterInjector appealing? Or is your use case an exception?

Have you spoken to the R8 team at all about this?

No, I didn't know that team existed TBH.

If there is a sensible workaround in the code to allow older Android versions, that is fine for me. We've already made some changes to allow for the more recent versions of Android.

from testparameterinjector.

I assumed this was because Anroid tests tend to use custom runners like RobolectricTestRunner.

Robolectric is for tests which run on the JVM and Google (at least google3) has a bit of an addiction to it to a degree which I don't think reflects non-Google usage. There certainly is widespread usage of Robolectric, but its runner is not used on every test, only subsets which actually touch Android APIs. There's still a lot of room for plain old JVM JUnit tests for things like business logic and lower-level storage/networking components. And then tests which touch a lot of Android APIs are the ones that run on the device, which use the regular JUnit runner (or Burst, or this).

Burst actually used to have a Robolectric module where we created a hybrid runner that supported both, but we eventually abandoned it.

Is the non-Google Android world different enough to make a TestParamterInjector appealing? Or is your use case an exception?

Hard to say in the general case, but we have non-zero Burst usage in our tests that run on Android. Anecdotally I know of one or two other companies using Burst in similar ways.

If there is a sensible workaround in the code to allow older Android versions, that is fine for me. We've already made some changes to allow for the more recent versions of Android.

Yeah it's a shame we have to do this. But unfortunately the current required minimum (API 26) imposed here is still a few years away from being realistic. Today 21-24 is the common range people are using as a minimum. I believe Google was looking at 19 or 21 as a minimum when I left (a year ago now).

By the way regarding

I'm trying to migrate our codebases from Burst in an effort to deprecate Burst

We just did this:

• Deprecation: square/burst@e6af132
• Blog post: https://code.cash.app/migrating-from-burst-to-testparameterinjector

from testparameterinjector.

We just did this:

Thanks so much for the deprecation and the blogpost! It means a lot to me and the other contributors :-).

There's still a lot of room for plain old JVM JUnit tests for things like business logic and lower-level storage/networking components.

Alright, in that case, it feels like supporting Android is indeed an important feature that should be maintained.

from testparameterinjector.