are there any best practices, how to test custom components in Compose? I have a custom `MyTextField...

# compose

[Peter Mandeljc]

are there any best practices, how to test custom components in Compose? I have a custom MyTextField composable and I would like somehow send text directly to the root of it. Atm I'm getting Failed to assert the following: (SetText is defined) .

[Peter Mandeljc]

For example, if I have following composable:

@Composable
fun MyTextField(...) {
    Box {
        Column {
            Row {
                BasicTextField(...)
            }
        }
    }
}

And use it like so:

@Composable
fun SomeScreen() {
   MyTextField(modifier = Modifiler.testTag("myTextField"))
}

Is it possible to send text to root of it like this:

// instrumented unit test
composeRule.onNodeWithTag("myTextField").performTextInput("banana")

[Peter Mandeljc]

Can I avoid having utility functions, that matches exactly the composable inside MyTextField (BasicTextField )?

[Peter Mandeljc]

Or if I ask a bit differently... how does compose test framework know, on which child composable to set text, when performTextInput is called on material TextField for example?

[Alex Vanyo]

I’d take a look at .semantics(mergeDescendants = true) and the overall documentation for semantics: https://developer.android.com/jetpack/compose/semantics

Even though you asked about testing, the test tools use the same semantic information that drives accessibility services. If you’re making a custom component, tweaking the semantics of it to work naturally with the test tools should go hand-in-hand to making sure the custom component works well with accessibility services too!

[Peter Mandeljc]

That seems exactly what I'm missing. Thanks!

[Lorenzo Neumann]

@Peter Mandeljc Hey, did you find a solution yet? The mergeDescendants approach does not yet work for me and I ended up setting the testTag as parameter on the composable and then use it on the text field itself.

[Peter Mandeljc]

Not sure if it's completely correct, but I did the following

modifier.semantics(
    mergeDescendanta = true,
    properties = {
        setText {
            onTextChanged(it.text),
            true
        }
    }
)

[Lorenzo Neumann]

Yeah, that also came to my mind, but with that the semantics of all composables are merged which I don't want as I also use buttons and images as siblings to my text field. But nervertheless, thanks!

[Peter Mandeljc]

I think you can still set mergeDescendants = false?

[Lorenzo Neumann]

That all did not work out the way I needed. I now ended up reworking my custom text field to only use the BasicTextField with a custom decoration box so that semantics are handled as with a normal text field.