A modern programming language that makes developers happier.

kotlinlang

I’m trying to use Compose instrumented tests to check that moving a discrete slider (with integer values) causes its associated text node to display the current slider value. I make the movement using `performTouchInput` and check the text with `hasText`. The way I devised to move the slider doesn’t work for all ranges, so I’m looking for suggestions for the best (correct) way to move it. (See :thread: for details.)

This is how I move the slider:
```composeTestRule.onNodeWithTag(
  testTag = "Slider").performTouchInput {
  down(topLeft)
  moveTo(topLeft + percentOffset(x = xOffsetPercent))
  up()
}.assertExists() // Force slider to show current position```
(I had achieved that through a bit of trial and error.)

This is how I check the text:
```composeTestRule.onNode(
  hasTestTag(testTag = "SliderValue")
    .and(hasText(expectedSliderValue))
).assertIsDisplayed()```
I set `xOffsetPercent = (position-sliderStartValue).toFloat()/(sliderEndValue-sliderStartValue)` and `expectedSliderValue = position.toString()`.

With `sliderStartValue = 1` and `sliderEndValue` anything between 2 and 12, the checks of all positions work out. But when I change `sliderEndValue` to 13 or greater, some of the checks fail (checking the `printToLog` I see the text has the “n-1” position). I suppose the way I am moving the slider is not accurate enough -- is there a better way to do it? Thanks.

(This is actually an attempted distillation of the problem I actually see in my app: moving from Material 3 1.0.0-alpha10 to 1.0.0-alpha11 caused my existing slider instrumented tests to break, without having changed anything else. Does anyone know what change in Material 3 could be affecting this as well? The behavior I discussed above exists on alpha 10 and 11, so that hasn’t helped me figure out what specifically affected my app’s tests.)

This is brittle. You're making assumptions on how exactly the slider converts pixel coordinates of an event to the underlying "active" area around a particular "tick" in the value range. There's also nothing here to account for any potential paddings or insets that the slider might have baked in (which can change over time as Material design evolves).

I agree it’s kludgy, although I’m trying to understand why it works for most slider settings but not all. I was assuming that by working in the x offset only I could control the position well enough (discrete sliders “round” to the nearest position).

In any case, what is the proper way to test a `Slider`? Having the kludgy “touch-only” simulation was better than nothing, but now I have nothing with alpha 11.

Do you want to test the slider itself (which would fall under the responsibility of the provider of that component), or the sync between your model and the components that are bound to it (slider and text)?

Primarily I want to test the syncing. (There was a time when `Slider` itself had issues, but I think I could assume it is stable now)

I want to test all the interactions in my app. I am able to test all buttons, drop-down menu items, etc., but `Slider` is the last piece for me.