Hello folks! I was wondering if there is any way of forcing the Robolectric idling strategy to work...

# compose

[nacholopez]

Hello folks!

I was wondering if there is any way of forcing the Robolectric idling strategy to work on tests? RobolectricDetector in the Compose codebase checks specifically for Robolectric runners by looking for specific traits in your runner, however at my current company we use a custom runner with a bunch of extra configuration that we can't remove and it doesn't fall into the categories checked: this runner we use doesn't extend AndroidJUnit4 nor the robolectric ones, but it is indeed a Robolectric runner.

Would it be possible to add some way of configuring the runner to let the composeTestRule know we are using Robolectric even if it doesn't seem so?

[Jelle Fresen [G]]

Hi, this is really valuable feedback. Could you file a bug at https://issuetracker.google.com/ in the "Jetpack Compose > UI Libraries > Testing" component with this feature request?

[nacholopez]

oh, I created it here https://partnerissuetracker.corp.google.com/issues/191899641 but with another component. Can I change the component here?

[Jelle Fresen [G]]

For supporting your case there are two ways we can go:
1. Open up all API you need to create a similar idling strategy as the RobolectricIdlingStrategy, so you can roll your own
2. Add API to let you influence the robolectric detection
My first instinct is that 2 is a workaround for the real problem, namely that the API is insufficient. Which leads me to think we should go for 1. It is a fine line to walk though, as the things you need to get access to are pretty low level and are not tested for unintended usages.

[Jelle Fresen [G]]

https://partnerissuetracker.corp.google.com/issues/191899641

Thanks, I'll move it to the right component

[nacholopez]

Yeah, I was looking at forking the rule code while the official issue might be looked at, and it was hard because most of the stuff needed is pretty low level so the amount of code to be carried over would be unmaintainable for us xD
For us, 2) would be enough, because maintaining our own idling strategy might be prone to break in updates, but this is just an outsiders perspective 🙂

1) would also be amazing, as long as we can access the Robolectric one (which is internal now), being able to use kotlin delegation on it would be amazing (so that we can hit the ground running)

[Jelle Fresen [G]]

Yeah, I was thinking along those lines as well.

[Jelle Fresen [G]]

The sad bit is that in the mean time I can't think of a workaround to your problem

[Jelle Fresen [G]]

(well, other than forking ui-test-junit4)

[nacholopez]

I kinda figured XD I couldn't see any way out with reflection either so that's what will end up happening in the meantime, forking a lot of that code