Any recommendations on the best way to use Fragments with Paparazzi?

[erawhctim]

Paparazzi tests work off of Views, but what if an app primarily uses Fragments for its screens? Are there patterns for instantiating a Fragment in a test and extracting its root layout view for use with Paparazzi?
I know I can inflate a View directly from a layout file in a Paparazzi test, but if the Fragment implementation is the main "view holder" for View references within that layout, I'm unsure how I would use Paparazzi effectively (without refactoring the Fragment's layout into a custom view).

I know you guys at Square typically shy away from Fragment usage and use Views directly, but I'm curious if someone in the community has tried to incorporate Paparazzi with Fragments, or any of the Fragment testing utilities, with any success.

[JakeWharton]

I know you guys at Square typically shy away from Fragment usage and use Views directly

This is a frequent mischaracterization of what we do.

We don't use fragments simply because they're poorly designed abstractions that do more harm than good. We have strong layering and encapsulation of our data layer, our presenter layer, and our rendering layer (where Views live). The rendering layer is regular views (not necessarily "custom") or Compose UI. The presentation layer speaks to the rendering layer through well-defined interfaces which means it's easy to drive the rendering layer with fake data.

Some people don't have the flexibility to abandon fragments. That's unfortunate, because they tend to muddy up clean layering and make otherwise simple things hard.

Think about testing just a TextView with paparazzi. You new up the view, call setText, and capture a screenshot. You can do this with different styles of text, settings on the view, and text content.

This is how our rendering layer works. You can efffectively new up any view hierarchy for a screen, call some functions on it to put it into a particular state, and then capture a snapshot. Nothing precludes you from doing this with fragments. In fact, it's probably a really good idea to do with this fragments so that you somewhat cleanly separate your rendering code from the presentation code.

Fragments, if you have to use them, are the place where you ideally put a bunch of glue code. It's where you glue together well-encapsulated components like presenters and views which can each exists and be tested on their own so you never actually have to test the fragments (except maybe implicitly in UI-based instrumentation tests). Your presenters can be tested on the JVM in unit tests and your views can be tested either in unit tests inside instrumentation or on the JVM with something like paparazzi.

I know it's not fun hearing that you have to do a bunch of work to make paparazzi or other forms of testing work when you're using fragments. But that's the reality when Google continues to push an abstraction that violates clean layering and actively inhibits good testing practices.

if the Fragment implementation is the main "view holder" for View references within that layout,

So, concretely, this is something that I would migrate to view binding which provides a single object that holds all references for you, or migrate your references to a plain old Java/Kotlin object. That object can have functions like setData(data: UiData) or whatever you need. Then your fragment would instantiate that type and hook up the data sources to that function and be done. Now you have an object dedicated to handling rendering that can be created both in the fragment and in paparazzi tests.

[erawhctim]

Thanks for the detailed response, Jake. I appreciate the extra context!

So, concretely, this is something that I would migrate to view binding which provides a single object that holds all references for you, or migrate your references to a plain old Java/Kotlin object. That object can have functions like setData(data: UiData) or whatever you need. Then your fragment would instantiate that type and hook up the data sources to that function and be done.

This is pretty close to what I was brainstorming in my head, and sounds reasonable given the fact that we'd have to incrementally adopt Paparazzi layout-by-layout anyway 👍