Customizing string rendering of view hierarchy

[pyricau]

Description

@zach-klippenstein and I are working on releasing https://github.com/square/radiography , a utility that renders both Android & Compose view hierarchies to readable strings.

Espresso errors include a string rendering of the view hierarchy, unfortunately that rendering is not as human readable as it could be.

At Square, I've replaced Espresso's string rendering with the output from Radiography. I did that with a giant hack, setting a FailureHandler delegate and using reflection to replace the Throwable's detailMessage field 💩💩💩. Shared in a tweet here: https://twitter.com/Piwai/status/1291771701584252928

It would be great if Espresso would provide a hook to set up a view hierarchy renderer. Also, if you feel comfortable with it, it could depend directly on Radiography in some way or offer it as an alternate impl (might be more involve to sign off on that?).

If you're ok with the idea of adding such an API I'm happy to open up a PR and we can take it from there.

[brettchabot]

@adazh any thoughts?

It sounds reasonable to me to allow customization of the view hierarchy error renderer. I personally am not a huge fan of the default renderer either.

I am personally usually really cautious about adding extra dependencies. Would one option be to just directly modify the existing renderer (HumanReadables) to make it more useful?

Alternatively, androidx.test lately has been using ServiceLoader for this type of thing. HumanReadables could allow swapping out alternative implementations . Take a look at ServiceLoaderWrapper and its usages. Then there could be a solution where if radiography is on the classpath, Espresso will automagically use its renderer.

[pyricau]

I am personally usually really cautious about adding extra dependencies.

Totally fair, I'd be cautious as well.

Would one option be to just directly modify the existing renderer (HumanReadables) to make it more useful?

It's always an option, but next thing you know we'll want to do even more and be back to exactly this spot.

If I understand the other options:

ServiceLoader

• Radiography could magically set itself as the renderer, though that'd require some initialization call on the Radiography side (or content provider hack..)
• Makes it easy for code like HumanReadables to pick up a dependency without changes to the broader API surface. Very much a local change, easy to implement.
• Makes this API hard to discover.

A new top level API in Espresso:

• Discoverable and straightforward to use
• More work in the Espresso codebase

I have a personal preference for the latter but could make both work.

As for connecting Espresso + Radiography:

• Could be done with classloading on the Espresso front, ie "check if HumanReadables Radiography implementation is in classpath and call default constructor on it if yes".
  • It's the most seamless experience
  • Makes Espresso have an optional dependency on Radiography. Not the worst, and loading a class with a default constructor is generally easy to keep backward compatible
• Could be done with Radiography providing a HumanReadables implementation, or an "set up" method, or a content provider to do that on app start via the ContentProvider app loading hack for the most seamless experience. The latter is functionally equivalent to doing it in Espresso, at the cost of one more provider (I'd stay away from the new androidx startup until it's more stable, because more dependency hell).

Radiography will be released this week or next.

[brettchabot]

It is a valid point about discoverability. API changes is another area are we are typically cautious about :) There is a process we follow where the different options are weighed and voted on. I can kick off the review process.

But first I wanted to clarify. Does Radiography require special initialization? I don't think content provider hacks should be needed. ServiceLoader already provides the classloading mechanism and ability to create an object with a default constructor. Radiography would just need to include resource metadata. Take a look at how Robolectric integrates with Espresso for an example: https://github.com/robolectric/robolectric/blob/master/robolectric/src/main/resources/META-INF/services/androidx.test.platform.ui.UiController

[pyricau]

Does Radiography require special initialization?

Nope. I had forgotten about the ability to auto load services via resources. In that case, no need for any special init.

How do you deal with multiple services or customization? E.g. that radiography service might need to be customized.

[brettchabot]

Multiple services could be a problem. Depending on use case, you could either throw or just pick the first one but warn.

Lack of good customization options is another issue with the ServiceLoader approach.

One option is to support both ServiceLoader and a direct API that allows overriding the renderer. Then users who need customization, or want to ensure determinism wrt cases where there are multiple services have a fallback.

WDYT?

[pyricau]

I like that!

Let me know how I can help. Happy to open PR, review, or whatever works for you.

[brettchabot]

Cool, can you start a PR?

[pyricau]

@brettchabot there you go: https://github.com/android/android-test/pull/746