Resumo

Os testes são considerados boas práticas no desenvolvimento de software e neste artigo você irá aprender a criar um teste para componente visual utilizando o Jetpack Compose. E para que você consiga realizar esse processo, vamos abordar:

  • A utilização do CreateComposeRule;
  • Como apresentar componentes em seu emulador;
  • Como usar @get:Rule para interagir de diversas formas com o seu componente;
  • Entender o que é semantics e a árvore de nós;
  • A utilização do Finders para encontrar componentes;
  • A utilização de Assertions para verificar se os componentes existem e se suas propriedades estão corretas;
  • A simulação de ações do usuário em um componente com Actions.

Vamos lá?

Banner da Escola de Mobile: Matricula-se na escola de Mobile. Junte-se a uma comunidade de mais de 500 mil estudantes. Na Alura você tem acesso a todos os cursos em uma única assinatura; tem novos lançamentos a cada semana; desafios práticos. Clique e saiba mais!

Introdução

Escrever testes unitários já é uma prática bem comum e difundida no mundo de desenvolvimento, pois como softwares são escritos por pessoas, qualquer um deles está propenso ao erro em algum nível. Por isso, a escrita de códigos que verifiquem os possíveis estados de uma aplicação é considerada uma boa prática, e não só os caminhos felizes (quando o usuário faz o que esperamos), mas também caminhos infelizes (quando eles nos surpreendem). Por exemplo, além de testar se um cálculo está certo, também é necessário verificar se o resultado está sendo mostrado para o usuário. Esse tipo de teste, em que se verifica o que está na tela do usuário, é chamado de testes de UI.

Neste artigo, vamos utilizar um projeto para você aprender na prática a realizar alguns testes. O projeto é um buscador de CEP, e nele você conseguirá adicionar um CEP e buscar informações como, bairro, logradouro, UF e DDD.

A princípio esses dados estão todos "simulados” para que você possa focar apenas nos testes. Se desejar, acesse o repositório do projeto e acompanhe todo o processo.

Adicionando as dependências

O primeiro passo para escrever testes é adicionar (se ainda não foram adicionadas) as bibliotecas de testes. Se você está utilizando o projeto disponibilizado neste artigo, elas já virão todas adicionadas. Porém, se deseja realizar os testes com outro projeto, é necessário adicionar as dependências. Para isso, faça o seguinte:

  • Abra o arquivo build.gradle e dentro dele cole o código a seguir:
dependencies {
    //Outras dependências acima
    androidTestImplementation("androidx.compose.ui:ui-test-junit4:$compose_version")
    debugImplementation("androidx.compose.ui:ui-test-manifest:$compose_version")
}

Perceba que você está usando duas formas de adicionar dependências:

  1. androidTestImplementation() que adiciona a dependência apenas no sourceSet de testes instrumentados (androidTest);
  2. debugImplementation() que adiciona a dependência apenas no ambiente de debug (ambiente de desenvolvimento, ou seja, não será adicionada na versão final pro usuário).

A primeira dependência só é visível dentro do androidTest, e a adicionamos já que precisa de um emulador para rodar o componente visualmente e fazer as asserções. Sendo assim, as classes que você criar estarão todas dentro do sourceSet de androidTest, pois os testes de Composables são considerados testes instrumentados.

Imagem com duas pastas. A primeira tem um ícone contendo apenas o contorno de uma pasta e o título br.com.devcapu.jetpackcomposetest (androidTest); a segunda tem um ícone de pasta na cor amarela e o título br.com.devcapu.jetpackcomposetest (test).
  • Depois disso, faça a sincronização do projeto clicando em sync no canto superior direito (essa opção só aparece se houver uma mudança no build.gradle).
IDE Android Studio com botão de sincronizar (sync) no canto superior direito.

Agora que você tem o projeto organizado, pode iniciar os testes no projeto. Vamos lá!

Estrutura básica do teste

O objetivo do seu primeiro teste é confirmar se o botão de procurar CEP está aparecendo na tela e se está desabilitado, já que ao carregar a tela pela primeira vez, nenhum CEP foi digitado. Veja o exemplo abaixo:

gif no qual o aplicativo “Buscador de CEP” é aberto, o campo de inserir o CEP está vazio e o botão “procurar CEP” está desabilitado, na cor cinza. Após digitar um número no campo CEP, o botão se torna verde, indicando que está habilitado.

Para escrever o teste é preciso a criação de uma classe que teste o composable SearchScreen, pois esse componente representa toda a tela que queremos testar. Para isso:

  1. Crie a classe SearchScreenTest;
  2. Crie o método deve_mostrarBotaoDeProcurarCepDesabilitado;
  3. Anote com @Test.

Abaixo, você tem a estrutura de como deve ficar o código:

class SearchScreenTest {
  @Test
  fun deve_mostrarBotaoDeProcurarCepDesabilitado() {

  }
}

O próximo passo para testar os composables é mostrá-los na tela. Para isso, você precisará de uma rule, que é um componente que intercepta a chamada de um método de teste e permite você fazer algo antes ou depois do método ser executado, assim como era no sistema de view.

  • Copie e cole o código @get:Rule val rule = createComposeRule(), acima do @Test. Seu código deverá ficar assim:
class SearchScreenTest {

    @get:Rule
    val rule = createComposeRule()

    @Test
    fun deve_mostrarBotaoDeProcurarCepDesabilitado() {

    }
}

O createComposeRule() é uma rule e com ela você vai conseguir não só lançar composables, como também interagir com eles. Para isso você precisa definir o conteúdo que vai ser mostrado no emulador usando o método setContent(), assim como é feito na Activity.

@Test
fun deve_mostrarBotaoDeProcurarCepDesabilitado() {
    rule.setContent { SearchScreen() } //Mostra o componente no emulador
}

Formas de buscar um composable

Como no sistema de composables não tem id (diferente do sistema de views), você precisa usar uma outra maneira de encontrar um componente na tela. A rule vai dar algumas opções para encontrar um componente.

Lista de sugestões indicando formas de procurar composables.

Temos 3 formas:

  • Procurar por textos: Funciona em componentes que possuem texto, como Text;
  • Procurar pela descrição do conteúdo: Funciona em conteúdos de imagem, por exemplo, Icon e Image;
  • Procurar pela tag: Seria o mais similar a um id, pois pode colocar uma tag em qualquer composable para que seja usada dentro dos testes. Caso o seu composable não possua nenhuma das outras opções, este é um caminho para encontrar o seu composable nos testes.

Semantics e árvore de nós

Essas características existem graças ao semantics do compose, que servem tanto para acessibilidade quanto para testes. Você pode alterar o semantics de um componente através de seu Modifier, como no exemplo abaixo:

Button(
    onClick = {  /* código de login */ },
    modifier = Modifier.semantics {
        contentDescription = "Botão para efetuar login no aplicativo"
    }
) {
    Text("Login")
}

O Button de procurar CEP, apesar de não ser um texto, possui um atributo text em seu semantics, pois quando foi escrito foi colocado um composable Text dentro dele, fazendo que herde esse atributo do filho.

Lista de atributos do componente `Button`, onde seu atributo `text`é herdado do componente filho, o  `Text`.

Na imagem acima você consegue ver os atributos do Button e pode encontrar esses atributos através do código:

rule.onNodeWithText("Login").printToLog("TAG")

O valor do atributo text que você encontra nele nada mais é do que o texto que está no seu elemento filho, o composable Text. Isso acontece porque o Compose de elementos na tela é representado por nodes (ou nós), e estes existem dentro de uma árvore de nós. Cada composable visível no aplicativo é um nó na árvore, e cada nó pode ter mais nós dentro dele. Abaixo, temos um exemplo dessa representação de nós:

Árvore de nós do aplicativo na aba de Layout Inspector do Android Studio.

Asserções

Agora que você sabe como funciona o semantics e a árvore de nós, busque o Button através do texto que ele herdou do Text e faça as verificações necessárias.

  • Para isso, insira o trecho rule.onNodeWithText("Procurar CEP").assertIsDisplayed() no seu método de teste.
@Test
fun deve_mostrarBotaoDeProcurarCepDesabilitado() {
    rule.setContent { SearchScreen() }

    rule.onNodeWithText("Procurar CEP").assertIsDisplayed()
}

A utilização do método assertIsDisplayed() é para validar se aquele componente, que nesse caso é o botão, realmente aparece.

O texto “Procurar CEP” foi definido no arquivo Search.kt. Lá você irá encontrar o composable responsável por ter o campo de texto que será inserido o CEP a ser procurado. A seguir, temos uma exemplo da implementação do composable que possui o texto que procuramos:

@Composable
fun SearchSection(
    uiState: SearchUiState = SearchUiState(),
    onCepChanged: (String) -> Unit = { },
    onButtonClicked: () -> Unit =  { },
) {
    Text(
        text = stringResource(R.string.insert_cep_label),
        style = MaterialTheme.typography.h4
    )

    Text(
        text = stringResource(R.string.search_info),
        style = MaterialTheme.typography.body1
    )

    TextField(
        modifier = Modifier
            .padding(top = 16.dp)
            .fillMaxWidth(),
        value = uiState.cep,
        onValueChange = onCepChanged,
        label = {
            Text(
                text = stringResource(R.string.cep_label),
                style = MaterialTheme.typography.caption
            )
        },
        singleLine = true,
        colors = TextFieldDefaults.textFieldColors(
            backgroundColor = Color.Transparent,
            focusedIndicatorColor = MaterialTheme.colors.primary,
            focusedLabelColor = MaterialTheme.colors.primary
        ),
        keyboardOptions = KeyboardOptions(
            keyboardType = KeyboardType.Number,
            imeAction = ImeAction.Search
        ),
        keyboardActions = KeyboardActions(onSearch = { onButtonClicked() }),
        isError = uiState.isShowingError,
    )
    if (uiState.isShowingError) {
        Text(text = stringResource(R.string.error_message))
    }
}

Feito isso, rode o teste no seu projeto e verifique se tem o resultado a seguir:

Lista com resultados dos testes, ícones verdes de checagem indicando que o teste passou.

Na imagem acima, você consegue analisar que os testes rodaram, quais classes de testes que foram executadas e quais testes daquela classe foram executados.

Se o resultado for igual ao da imagem acima, perfeito! Seu teste está passando. Mas não é só isso, certo? Porque além de passar também é preciso garantir que botão está desabilitado, já que não temos nenhum CEP digitado quando o aplicativo é aberto, conforme exemplo da imagem a seguir:

Tela do aplicativo buscador de CEP, com o texto insira seu CEP e botão desabilitado da cor cinza com o texto Procurar CEP.

Para verificar se um composable está habilitado é preciso fazer a validação com o método assertIsNotEnabled(). Faça conforme código a seguir:

@Test
fun deve_mostrarBotaoDeProcurarCepDesabilitado() {
    rule.setContent { SearchScreen() }

    val button = rule.onNodeWithText("Procurar CEP")
    button.assertIsDisplayed()
    button.assertIsNotEnabled()
}

Se você rodar o teste, ele deve continuar passando corretamente.

Pronto! O teste para verificar se o botão estava desabilitado foi feito e agora vamos fazer o teste para verificar se o botão está habilitado. Vamos lá!

Simulando ações no componentes

Para verificar se o botão está habilitado quando tiver um CEP válido você irá utilizar a mesma estrutura de antes, modificando apenas a verificação botão habilitado:

@Test
fun deve_mostrarBotaoDeProcurarCepHabilitado_QuandoCepForValido() {
    rule.setContent { SearchScreen() }

        val button = rule.onNodeWithText("Procurar CEP")
    button.assertIsDisplayed()
    button.assertIsEnabled()
}

E para realizar teste, você precisa digitar um CEP válido no TextField.

  • Insira o código rule.onNodeWithText("CEP") acima da procura do Button para procurar o TextField.
@Test
    fun deve_mostrarBotaoDeProcurarCepHabilitado_QuandoCepForValido() {
        rule.setContent { SearchScreen() }

        rule.onNodeWithText("CEP")

        val button = rule.onNodeWithText("Procurar CEP")
        button.assertIsDisplayed()
        button.assertIsEnabled()
    }
}

E a partir dele você poderá simular diversas ações no componente, conforme imagem abaixo:

Lista com sugestões de ações que podem ser feitas no componente Button.

Contudo, para alcançar o objetivo desse teste, o que nos será válido é a performTextInput(). E para isso, basta inserir o código a seguir:

rule.onNodeWithText("CEP").performTextInput("10001111")

Agora rode o teste e analise o resultado:

Resultado do teste indicando que e o método de teste está falhando.

Você perceberá que ele não está passando, já que, a digitação está sendo realizada. O que acontece é que o componente ainda não sabe o que fazer quando um valor é digitado, pois precisa atualizar o estado.

Assim, é preciso fazer igual se faz na Activity, criando um novo estado a cada carácter digitado, conforme código abaixo:

rule.setContent {
    var state by remember { mutableStateOf(UiState()) }
    SearchScreen(
        uiState = state,
        onCepChanged = {
            val searchUiState = SearchUiState(cep = it)
            state = state.copy(
                searchUiState = searchUiState,
                isButtonEnabled = it.isAValidCep()
            )
        }  
    )
}

Com o estado atualizando, rode o teste novamente e o botão deve estar habilitado.

Lista com resultados dos testes, ícones verdes de checagem indicando que o teste passou.

Esses processos confirmam o quanto o teste é fundamental no desenvolvimento de aplicativos, concorda? Pronto, agora você já tem uma boa base para criar seus primeiros testes com Jetpack Compose!

Conclusão

Neste artigo você aprendeu a criar testes para os componentes que usam o Jetpack Compose. Foi abordado que o rule além de nos permitir lançar um componente, conseguimos interagir com ele de 3 maneiras:

  • Finders: Permite achar um ou mais nodes;
  • Assertions: Permite verificar se um node existe ou tem alguma propriedade;
  • Actions: Simula eventos do usuário como cliques e gestos.

Porém, existem muitos métodos que podem ser utilizados e esse post não conseguiria abordar todos eles, mas existe um cheatsheet que a equipe do Android disponibilizou pra que você possa usar como referência sempre que precisar.

Se você quiser se aprofundar mais nesse tema, recomendamos a documentação do android que tem uma parte especifica mostrando cada detalhe sobre testes com compose. E claro, aqui na Alura temos uma Formação Jetpack Compose completinha para você aprender ainda mais.

Bons estudos!

Felipe Moreno Borges
Felipe Moreno Borges

Sou graduado em Ciência da Computação e atualmente estou cursando um MBA em Desenvolvimento Mobile. Sou apaixonado por tecnologia, vejo nela a possibilidade de melhorar a vida das pessoas além de uni-las. Meu foco principal está voltado para o desenvolvimento mobile, com especialização nas plataformas Android e iOS, utilizando linguagens como Java, Kotlin e Swift. Minha expertise abrange algoritmos, estruturas de dados, bancos de dados e redes. Uma das minhas realizações foi liderar a migração de projetos

Veja outros artigos sobre Mobile