Add support for render mode SHRINK for AccessibilityRenderExtension

[geoff-powell]

Fixes #1350

[jrodbx]

Curious: why move from the unit test to the plugin test? It'd be nice keeping the former, unless there's a good reason.

Basically, the commit prior: https://github.com/cashapp/paparazzi/compare/c3e10703ecd6daab2a6f30e8118c511680437481..39280d0a467518e4b36799cfc25ec6c8ea16ad19

[geoff-powell]

Cool, got a comment in slack about moving it. I reverted that change to make the change smaller and straight forward

[VirtualParticle]

Thank you for working on this! One thing I'll note is that it seems like this still runs into an issue if the content description takes up more space than the actual content. Take this test, for example:

@Test
fun `verify long content description`() {
  paparazzi.snapshot {
    Text(
      text = "Text",
      modifier = Modifier
        .padding(10.dp)
        .semantics {
          contentDescription = "This is a very long content description"
        },
    )
  }
}

It produces this screenshot:

Ideally, the test would recognize that the accessibility info is bigger and the screenshot would expand to fit the content description. Might be out-of-scope for this though.

[jrodbx]

nit: can we combine this with AccessibilityRenderExtensionTest + TestParameterInjector? Looks like renderingMode is the only argument that differs between the two.

[geoff-powell]

Thank you for working on this! One thing I'll note is that it seems like this still runs into an issue if the content description takes up more space than the actual content. Take this test, for example:

@Test
fun `verify long content description`() {
  paparazzi.snapshot {
    Text(
      text = "Text",
      modifier = Modifier
        .padding(10.dp)
        .semantics {
          contentDescription = "This is a very long content description"
        },
    )
  }
}

It produces this screenshot: Ideally, the test would recognize that the accessibility info is bigger and the screenshot would expand to fit the content description. Might be out-of-scope for this though.

Ya so that issue is due to the text having to be rendered after draw and not being part of the layout scope. Currently paparazzi render extensions execute on 1 layout pass. Unfortunately, we can only gather compose semantics after layout. Still thinking through other ways to fix this limitation