Robolectric Emulator(Roborazzi Emulator)

[takahirom]

I've realized that we can create an emulator using Robolectric Native Graphics. This is just a demo, but it works. I'm wondering if there are any use cases for this.

screencast.2023-10-08.14-49-52.mp4

[JoseAlcerreca]

I want to know more :) I guess it takes a screenshot on idle and displays it on the UI?

[jeprubio]

Could that be useful to run the tests on multiple devices/configurations?

Something like what Test Harness does for compose.

I mean without having to create multiple classes with annotations like @Config(qualifiers = RobolectricDeviceQualifiers.*), which is the only way I can think of to achieve that for now (in tests without compose).

[sergio-sastre]

Probably for debugging purposes if you can see what is displayed before the screenshot is taken, and you give an option to “stop/sleep” for x seconds

[takahirom]

Thank you for your feedback. I think it will be useful for debugging. Here's what I'm thinking:
The reason I use a function is that we might want to debug a specific function rather than running all tests.

  @Test
  fun emulator() {
    onView(ViewMatchers.isRoot())
      .roboNativeGraphicsEmulator()
  }

(when you click Dump)

[sergio-sastre]

Thank you for your feedback. I think it will be useful for debugging. Here's what I'm thinking: The reason I use a function is that we might want to debug a specific function rather than running all tests.

  @Test
  fun emulator() {
    onView(ViewMatchers.isRoot())
      .roboNativeGraphicsEmulator()
  }

(when you click Dump)

Thinking carefully, this makes sense not only for Roborazzi tests but also for Robolectric UI tests with RNG.

Sometimes they fail and I resort to run them on the emulator (shared test pattern) to see why they fail. This is definitely sth that would help debugging such tests without the need to making them “shared” between instrumentation & unit tests

[sergio-sastre]

Could that be useful to run the tests on multiple devices/configurations?

Something like what Test Harness does for compose.

I mean without having to create multiple classes with annotations like @Config(qualifiers = RobolectricDeviceQualifiers.*), which is the only way I can think of to achieve that for now (in tests without compose).

@jeprubio
It's not the only way indeed. The easiest is to use cumulative qualifiers and set them dynamically by calling e.g. RuntimeEnvironment.setQualifiers("+night")

I've just written a blog post about that:
Efficient testing with robolectric roborazzi across many ui states devices and configurations

Moreover, you can also achieve that by using an ActivityScenario (which is compatible with Robolectric), launching an EmptyActivity whose context has the desired configuration, and inflating your View in it. That has the extra advantage of allowing you to set a custom xml theme and use pseudolocales, which are not supported via Robolectric qualifiers.
That's how AndroidUiTestingUtils supports it via RobolectricActivityScenarioForView/Composable

[jeprubio]

@sergio-sastre Thanks! That's really helpful. I did know and use the cumulative qualifiers annotations but I didn't know about RuntimeEnvironment.setQualifiers() for example. For xml I was launching a DummyActivity with a dummy layout and inflating the xml in it.

These days I'm a bit busy with my new home but this week I'll find a moment to read more in detail all that article, I'm sure I'll learn from that. Thanks a lot!

[yschimke]

What about if instead of running it's own UI, it exposed the same hooks that Android Emulators do for returning images, and processing input.

Would be pretty useful tool for interactive compose previews, similar to the Android Studio previews, but based on a more open approach. A good base to build features like a VS Code preview support.

(possibly relevent? - https://github.com/google/android-emulator-webrtc)