Hey, I’m using Lottie with Compose - and the animation repeats indefinitely. For instrumented tests,...

# compose

[Tim Malseed]

Hey, I’m using Lottie with Compose - and the animation repeats indefinitely. For instrumented tests, this means the test gets stuck waiting for composition to complete.

I’ve tried setting the composeTestRule.mainClock autoAdvance to false, and then manually advancing the clock - but this doesn’t work very well when I actually want the UI test to take control of the clock.

Lottie has the ability to pass in a property representing whether an animation should run a finite number of times, or infinitely. I could pass in a different value for this to the Composable - but this feels akin to making something mutable just for the purpose of testing..

[Tim Malseed]

I know the ComposeTestRule automatically disables animations when using the Compose animation APIs..

[Tim Malseed]

But, this doesn’t seem to affect Lottie.

[Tim Malseed]

Should I be injecting a different value for the number of animation iterations, depending on whether it’s test or production? Or is there a better approach?

[Tim Malseed]

OK, I think I was just a but reluctant to inject the flag to toggle the number of iterations. I’ve made it a property of the ViewModel, and I just inject a different value in my test DI module

[Benoît]

Instead of a value in the VM you can probably use a composition local. It would make your Lottie Composable more reusable

[Tim Malseed]

I did see this suggested elsewhere, but I wasn’t sure how/why? How would I then provide a different value for testing?

[Tim Malseed]

Feel free to ignore that question, I just need to read up on Composition Local

[Benoît]

No need to explain the “how” since you now know how it works, the “why” is pretty simple.
It’s to be able to run your composable without any ViewModel so they’re not tight to any particular feature. Especially when it comes to very basic components like Lottie animations which are basically the same type of things as Image() and you wouldn’t want these to rely on any ViewModel

[Tim Malseed]

Yep, makes sense to me. Thanks for this.