Fix Shuffle and Repeat references in tests

PiperOrigin-RevId: 728309204
This commit is contained in:
jbibik 2025-02-18 12:12:55 -08:00 committed by Copybara-Service
parent 90844f11e8
commit 4045acd13b
2 changed files with 4 additions and 4 deletions

View File

@ -48,7 +48,7 @@ class RepeatButtonStateTest {
} }
@Test @Test
fun buttonClicked_withLimitedNumberOfModes_playerShuffleModeChangedToNextInSequence() { fun buttonClicked_withLimitedNumberOfModes_playerRepeatModeChangedToNextInSequence() {
val player = TestPlayer() val player = TestPlayer()
val state = RepeatButtonState(player, listOf(Player.REPEAT_MODE_OFF, Player.REPEAT_MODE_ONE)) val state = RepeatButtonState(player, listOf(Player.REPEAT_MODE_OFF, Player.REPEAT_MODE_ONE))
assertThat(state.repeatModeState).isEqualTo(Player.REPEAT_MODE_OFF) assertThat(state.repeatModeState).isEqualTo(Player.REPEAT_MODE_OFF)

View File

@ -60,9 +60,9 @@ class ShuffleButtonStateTest {
@Test @Test
fun playerSetShuffleModeAndOnClick_inTheSameHandlerMessage_uiStateSynchronises() { fun playerSetShuffleModeAndOnClick_inTheSameHandlerMessage_uiStateSynchronises() {
// The UDF model of Compose relies on holding the Player as the single source of truth with // The UDF model of Compose relies on holding the Player as the single source of truth with
// RepeatButtonState changing its state in sync with the relevant Player events. This means that // ShuffleButtonState changing its state in sync with the relevant Player events. This means
// we should never find ourselves in a situation where a button's icon (here: determined by // that we should never find ourselves in a situation where a button's icon (here: determined by
// RepeatButtonState.repeatModeState) is out of sync with the Player's repeat mode. It can cause // ShuffleButtonState.shuffleOn) is out of sync with the Player's shuffle mode. It can cause
// confusion for a human user whose intent to toggle the mode will not be fulfilled. The // confusion for a human user whose intent to toggle the mode will not be fulfilled. The
// following test tries to simulate this scenario by squeezing the 2 actions together (setter + // following test tries to simulate this scenario by squeezing the 2 actions together (setter +
// onClick) into a single Looper iteration. This is a practically unlikely scenario for a human // onClick) into a single Looper iteration. This is a practically unlikely scenario for a human