Hey… I’m implementing Accessibility Tests with Com...

# compose

[Jordan Silva]

Hey…
I’m implementing Accessibility Tests with Compose and so far the only way that I’ve found to do is using ComposeRule and Semantics.
I tried to cover more Accessibility tests like contrast, spacing, etc, with Espresso, by enabling AccessibilityChecks.enable(). However I noticed the View Hierarchy printed from Espresso only had a ComposeView and AndroidComposeView with no extra information like text, content description.

+---->AndroidComposeView{id=-1, visibility=VISIBLE, width=1080, height=1808, has-focus=false, has-focusable=true, has-window-focus=true, is-clickable=false, is-enabled=true, is-focused=false, is-focusable=true, is-layout-requested=false, is-selected=false, layout-params=android.view.ViewGroup$LayoutParams@6460a4, tag=null, root-is-layout-requested=false, has-input-connection=false, x=0.0, y=0.0, child-count=1} 
|
+----->RippleContainer{id=-1, visibility=VISIBLE, width=0, height=0, has-focus=false, has-focusable=false, has-window-focus=true, is-clickable=false, is-enabled=true, is-focused=false, is-focusable=false, is-layout-requested=true, is-selected=false, layout-params=android.view.ViewGroup$LayoutParams@ef261c2, tag=null, root-is-layout-requested=false, has-input-connection=false, x=0.0, y=0.0, child-count=1} 
|
+------>RippleHostView{id=-1, visibility=VISIBLE, width=0, height=0, has-focus=false, has-focusable=false, has-window-focus=true, is-clickable=false, is-enabled=true, is-focused=false, is-focusable=false, is-layout-requested=true, is-selected=false, layout-params=android.view.ViewGroup$LayoutParams@508ebd3, tag=null, root-is-layout-requested=false, has-input-connection=false, x=0.0, y=0.0}

Another issue I had migrating to Compose is that our Espresso tests will fail after a simple screen migration. 😐
If we have a simple screen with just a Text. And we migrate to Compose, Espresso won’t find that Text anymore.
So, just creating an Activity with a Text, and changing that to ComposeView and adding a Compose Text (with the same information). If we try to do the following code, it won’t find the View.

Espresso.onView(withText(R.string.app_intro)).check(matches(isDisplayed()))

I found this answer, so I guess I have to implement new tests while migrating to compose:
https://github.com/android/compose-samples/commit/a6907c5dc236e9c18f062c44453b1c15359962cf#commitcomment-51521777

----------
So, after this huge text, I have 2 questions 😬
1. Will Compose Semantics Test or Test libraries have something similar to Espresso AccessibilityChecks.enable() ?
2. How can I check colors, images and other components properties like Modifiers/borders? These are not visible with SemanticsNode using Jetpack Compose tests.
a. Right now I’m having to check with Snapshots (then some workarounds on top of Snapshot to work across different APIs)

[Zach Klippenstein (he/him) [MOD]]

Please post longer messages and especially code snippets in threads - there's a lot of content in this channel and it helps keep the channel itself readable for people scrolling by.

[Zach Klippenstein (he/him) [MOD]]

Yes, espresso tests won't work as-is with Compose because espresso operates only on views, not the accessibility tree, at least by default.

[Jordan Silva]

@Zach Klippenstein (he/him) [MOD] Yes, I noticed (also from the reply from @ppvi in that github thread).
But does Compose Test Suite or any Android Test suite provides some way to validate these other properties (such as colors, background, images, modifiers, borders, etc)?

[Jordan Silva]

With Android Views we could create custom components with custom attributes, then validate these somehow.
With Compose we can create companion objects or vals to hold such values, then, unit test these values. But it doesn’t guarantee that our component is actually consuming those values. So, in the end, it doesn’t test anything. 😐

[Zach Klippenstein (he/him) [MOD]]

I don’t have a good answer there, besides screenshot testing (which isn’t very satisfying)

[Zach Klippenstein (he/him) [MOD]]

You can get the pixels from a semantics node using captureToImage() and do mini-screenshot tests on that.

[Jordan Silva]

I'm doing this. And having some other hacks to test components only. I'm having to center it in the activity, otherwise I've different gradient shadow color from the top bar depending for different API levels. :|
To test focus state for example, I'm using UiAutomator to navigate down and taking screenshots and comparing it when a component is focused.
Anyway, thanks.
I was just wondering if you guys have thought about this, or have some plans to enable & support more things with Testing APIs.

[Zach Klippenstein (he/him) [MOD]]

Can you file a feature request bug?

[Zach Klippenstein (he/him) [MOD]]

also see https://issuetracker.google.com/198122348

[Jordan Silva]

Cool 🙂
Thanks!

[Jordan Silva]

[For all] To validate components and workaround some missing properties. I’m adding semantics properties to validate like component colors.

.semantics {
                set(BackgroundColor, backgroundColor.toArgb())
                set(ForegroundColor, foregroundColor.toArgb())
      ...
            }

[ppvi]

the problem with that approach is that you're not testing your app, just the semantics definitions

[ppvi]

but as long as they refer to the same variable I guess it's better than nothing

[Jelle Fresen [G]]

As long as the semantics property is set to value that the app uses, then you're testing the app imho

[Jordan Silva]

@ppvi Yeah, you’re right. So far, I couldn’t find a better way. I’m trying to cover all scenarios with Screenshots, Semantics and some custom ones that I’m creating.
So I could cover like:
• Look & Design with Screenshots + Semantics.
• Different States (Disabled, Focused, etc).
• Accessibility with Semantics + Semantics (WIP)
◦ For ContrastRatio I’m adding Custom Semantics for Foreground/Background/TextSize.

[Jordan Silva]

But only downside so far to promote Jetpack Compose migration across the company is the need to rewrite Instrumented tests using Espresso.
It’s hard to promote to a team and say, yeah, do you know that test you spent 6 months to get it done? You need to rewrite that. 😅

[Jordan Silva]

I’m trying to do a Test Framework here to make their lives easier and give a bunch of things (functions + extensions+ checks) “out-of-the-box”.

[Zach Klippenstein (he/him) [MOD]]

6 months to write a ui test?

[Jordan Silva]

Hahaha... I'm exaggerating a little bit.
But if you consider having to implement e2e tests and making them stable (fixing most of the flakiness) for big or complex apps. It's not crazy.
Of course having in mind that people have meetings, and aren't spending 36-40hs/week only working on tests.

[Zach Klippenstein (he/him) [MOD]]

I definitely get that. One thing that might help sell is that compose UI tests are, by design, susceptible to much less of the flakiness that has plagued espresso tests.

[Zach Klippenstein (he/him) [MOD]]

So there are wins you can get even just by migrating your tests themselves

[ppvi]

(Flakiness comes from Views and the platform, not from Espresso)

[Jordan Silva]

Yep. Not handling Espresso Idling Resources well. Thread problems. Emulator issues. Memory leaks. Etc.
I agree. But in the end, people will blame the entire thing not handling magically stuff for them. Or not being clear where or why the failure is happening.