Padrões comuns

Você pode testar o app do Compose com abordagens e padrões bem estabelecidos.

Testar de forma isolada

O ComposeTestRule permite iniciar uma atividade mostrando qualquer elemento combinável, como seu aplicativo completo, uma única tela ou um elemento pequeno. Também é uma prática recomendada verificar se os elementos combináveis estão encapsulados corretamente e funcionam de forma independente, permitindo testes de interface mais fáceis e focados.

Isso não significa que você só pode criar testes de IU de unidade. Os testes voltados para partes maiores da IU também são muito importantes.

Acessar a atividade e os recursos depois de definir seu conteúdo

Muitas vezes, você precisa definir o conteúdo em teste usando composeTestRule.setContent e também acessar recursos da atividade, por exemplo, para declarar que um texto mostrado corresponde a um recurso de string. No entanto, não é possível chamar setContent em uma regra criada com createAndroidComposeRule() se a atividade já a chama.

Um padrão comum para fazer isso é criar um AndroidComposeTestRule usando uma atividade vazia, como ComponentActivity.

class MyComposeTest {

    @get:Rule
    val composeTestRule = createAndroidComposeRule<ComponentActivity>()

    @Test
    fun myTest() {
        // Start the app
        composeTestRule.setContent {
            MyAppTheme {
                MainScreen(uiState = exampleUiState, /*...*/)
            }
        }
        val continueLabel = composeTestRule.activity.getString(R.string.next)
        composeTestRule.onNodeWithText(continueLabel).performClick()
    }
}

Observe que a ComponentActivity precisa ser adicionada ao arquivo AndroidManifest.xml do app. Para ativar, adicione esta dependência ao módulo:

debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")

Propriedades de semântica personalizadas

Você pode criar propriedades semantics personalizadas para expor informações a testes. Para fazer isso, defina um novo SemanticsPropertyKey e disponibilize-o usando a SemanticsPropertyReceiver.

// Creates a semantics property of type Long.
val PickedDateKey = SemanticsPropertyKey<Long>("PickedDate")
var SemanticsPropertyReceiver.pickedDate by PickedDateKey

Agora, use essa propriedade no modificador semantics:

val datePickerValue by remember { mutableStateOf(0L) }
MyCustomDatePicker(
    modifier = Modifier.semantics { pickedDate = datePickerValue }
)

Nos testes, use SemanticsMatcher.expectValue para declarar o valor da propriedade:

composeTestRule
    .onNode(SemanticsMatcher.expectValue(PickedDateKey, 1445378400)) // 2015-10-21
    .assertExists()

Aviso: use propriedades semânticas personalizadas somente quando for difícil fazer a correspondência a um item específico usando os localizadores e matchers fornecidos. Não é recomendado usar propriedades semânticas personalizadas para expor propriedades visuais como cores, tamanho de fonte ou raio de cantos arredondados, porque isso pode poluir o código de produção e implementações erradas podem gerar bugs difíceis de encontrar.

Verificar a restauração do estado

Verifique se o estado dos elementos do Compose é restaurado corretamente quando a atividade ou processo é recriado. Faça essas verificações sem depender da recriação de atividades com a classe StateRestorationTester.

Essa classe permite simular a recriação de um elemento combinável. É especialmente útil verificar a implementação de rememberSaveable.

class MyStateRestorationTests {

    @get:Rule
    val composeTestRule = createComposeRule()

    @Test
    fun onRecreation_stateIsRestored() {
        val restorationTester = StateRestorationTester(composeTestRule)

        restorationTester.setContent { MainScreen() }

        // TODO: Run actions that modify the state

        // Trigger a recreation
        restorationTester.emulateSavedInstanceStateRestore()

        // TODO: Verify that state has been correctly restored.
    }
}

Testar diferentes configurações de dispositivos

Os apps Android precisam se adaptar a muitas condições em mudança: tamanhos de janela, localidades, tamanhos de fonte, temas escuros e claros e muito mais. A maioria dessas condições é derivada de valores no nível do dispositivo controlados pelo usuário e expostas com a instância atual do Configuration. Testar configurações diferentes diretamente em um teste é difícil, já que o teste precisa configurar propriedades no nível do dispositivo.

DeviceConfigurationOverride é uma API somente para teste que permite simular diferentes configurações de dispositivos de maneira localizada para o conteúdo @Composable em teste.

Observação: DeviceConfigurationOverride está disponível no Compose 1.7.0-alpha03

O objeto complementar de DeviceConfigurationOverride tem as seguintes funções de extensão, que substituem as propriedades de configuração no nível do dispositivo:

• DeviceConfigurationOverride.DarkMode(): substitui o sistema pelo tema escuro ou claro.
• DeviceConfigurationOverride.FontScale(): substitui a escala da fonte do sistema.
• DeviceConfigurationOverride.FontWeightAdjustment(): substitui o ajuste de espessura da fonte do sistema.
• DeviceConfigurationOverride.ForcedSize(): força uma quantidade específica de espaço, independente do tamanho do dispositivo.
• DeviceConfigurationOverride.LayoutDirection(): modifica a direção do layout (da esquerda para a direita ou da direita para a esquerda).
• DeviceConfigurationOverride.Locales(): substitui a localidade.
• DeviceConfigurationOverride.RoundScreen(): substitui a opção se a tela for redonda.

Para aplicar uma substituição específica, envolva o conteúdo em teste em uma chamada para a função de nível superior DeviceConfigurationOverride(), transmitindo a substituição para ser aplicada como um parâmetro.

Por exemplo, o código abaixo aplica a substituição DeviceConfigurationOverride.ForcedSize() para mudar a densidade localmente, forçando o elemento combinável MyScreen a ser renderizado em uma janela grande no modo paisagem, mesmo que o dispositivo em que o teste está sendo executado não ofereça suporte direto a esse tamanho de janela:

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.ForcedSize(DpSize(1280.dp, 800.dp))
    ) {
        MyScreen() // will be rendered in the space for 1280dp by 800dp without clipping
    }
}
DeviceConfigurationOverrideSnippets.kt

Para aplicar várias substituições juntas, use DeviceConfigurationOverride.then():

composeTestRule.setContent {
    DeviceConfigurationOverride(
        DeviceConfigurationOverride.FontScale(1.5f) then
            DeviceConfigurationOverride.FontWeightAdjustment(200)
    ) {
        Text(text = "text with increased scale and weight")
    }
}
DeviceConfigurationOverrideSnippets.kt

Outros recursos

• Testar apps no Android: a página de destino principal de testes do Android oferece uma visão mais ampla dos princípios básicos e das técnicas de teste.
• Conceitos básicos de testes:saiba mais sobre os principais conceitos por trás de testes de apps Android.
• Testes locais: é possível executar alguns testes localmente na sua própria estação de trabalho.
• Testes instrumentados:é uma prática recomendada executar testes instrumentados. Ou seja, testes executados diretamente no dispositivo.
• Integração contínua: a integração contínua permite integrar seus testes ao pipeline de implantação.
• Teste diferentes tamanhos de tela:com alguns dispositivos disponíveis para os usuários, teste diferentes tamanhos de tela.
• Espresso: embora seja destinado a interfaces baseadas em visualização, o conhecimento do Espresso ainda pode ser útil para alguns aspectos dos testes do Compose.