Android com Kotlin: testes instrumentados

Testes de instrumentação - Apresentação

Bem-vindo a mais um curso de Android com Kotlin e esse é um curso de testes instrumentados. Eu sou Felipe, desenvolvedor e instrutor aqui na Alura e eu vou guiar você durante esse curso.

Por motivo de acessibilidade eu vou fazer a minha autodescrição. Eu sou um homem negro de cabelo curto e barba curta. Eu estou usando óculos e durante esse curso, na maior parte do tempo, eu vou estar com um moletom marrom.

Para começar, os pré-requisitos desse curso são que você tenha conhecimentos sobre Room no Android, ou seja, gerenciar o banco de dados, fazer migrações e também sobre teste de unidade, que é o curso anterior a esse.

Se você se sentir confortável com ambos os conceitos, tanto do Room quanto de teste de unidades, você vai sentir mais facilidade durante esse curso.

O projeto que vamos acabar desenvolvendo é um Orgs. O Orgs é esse sistema que gerencia produtos orgânicos. Então, nós somos capazes de cadastrar um produto orgânico, também editar e excluir. Nós podemos também fazer o login ou cadastro.

Os conceitos que nós vamos aprender é como pegar algum elemento da tela e verificar se ele realmente está lá. Como que nós conseguimos fazer ações em cima desses elementos, como por exemplo, clicar, escrever.

Nós também conseguimos esconder o nosso teclado em determinados momentos e fazer verificações.

Além disso nós vamos aprender sobre tipo de building e como que nós podemos criar novos tipos de building dentro do Android para criar diferentes bancos de dados.

Eu espero que você goste e até a próxima aula.

Testes de instrumentação - Conhecendo o projeto

Bom, então, vamos entender agora como que o nosso projeto está organizado, como que a nossa estrutura de pastas, de testes e tudo mais.

Eu vou abrir a nossa aba de Project que fica no menu da esquerda e eu vou procurar pelo nosso Orgs de teste. Então, esses são os testes que nós escrevemos no curso anterior de testes de unidades.

Se você não viu, eu recomendo muito que você veja, porque nós vamos continuar usando o mesmo projeto do final do curso de testes de unidades como uma base para esse.

Então, vamos entrar no nosso ProdutoTests, eu vou fechar o emulador, e nós temos diversos testes aqui. Nós verificamos se o valor de um produto é valido, ou seja, se ele tem que aceitar um valor que seria considerado normal. Ele também indica quando houver algum valor que é suspeito ou estranho como, por exemplo, uma carambola que custa mais de 100 reais, que é o caso.

Ele também deve ser capaz de indicar os valores que são inferiores a zero ou igual a zero. Um produto não deveria ser de graça e nem negativo, e é o que nós fazemos aqui nesse último teste.

Nós usamos o Kluent para escrever esses teste de uma forma bem fluente, bem humanizada. Então, nós já temos diversos testes aqui. Além disso nós temos aqui o nosso ProdutoRepository teste que é onde nós vamos testar alguns objetos simulados através de mocks.

Então no ProdutoRepositoryTests estamos simulando dao, dizendo que dependendo do método ele vai fazer uma certa ação que nós vamos dizer qual é.

Então, quando nós formos chamar o dao.salva, na verdade, ele vai retornar um unity. Nós não vamos ter um dao de verdade, nós vamos ter um simulado e, assim, nós conseguimos testar o nosso objetivo, que é o produtoRepository, e verificar se ele está chamando o nosso dao.

Nós aprendemos sobre simulações. Além disso, nós temos ali o nosso código que nós diríamos que é o nosso código de release que é o que vai para o usuário.

Então, a estrutura não mudou quase nada. A única diferença é que agora aquela busca por produtos de um usuário foi removida por motivos didáticos. A ideia é que quando ele tiver na lista de produtos, ele vai buscar todo os produtos que estão no banco de dados, e não apenas os produtos de um usuário.

Mas todo o resto continua o mesmo. Nós temos uma camada de acesso aos dados que é a database, temos uma camada de funções de ajuda que são as nossas extensions, também temos uma camada de modelos, ou seja, são os objetos que vão representar algo do mundo real, como um produto, um usuário.

Além disso, eles também servem como um modelo para o nosso banco de dados. Então, ele vai dizer o que é um produto, quais campos vão estar no banco de dados e quais não. Como é o caso do valor é válido que não é um campo que o Room vai entender, porque nós estamos usando @Ignore.

Isso vai servir aqui para o nosso usuário, ele também é uma entidade que também vai ser mapeada para o banco de dados e alguns campos vão ser ignorados.

Temos a nossa camada de preferences, que nós vamos salvar informações do usuário para ver se ele já está logado, se ele já criou uma conta. Então, está dentro do usuário preference.

E a parte de nossa UI que seria a nossa tela. Então, na UI vai ter todos os códigos de tela, a nossas activities, os dialogues e as nossas listas. Então, veja que quase nada mudou, apenas esse detalhe que nós não buscamos os produtos de um usuário e, sim, de todos os produtos que estão no banco de dados.

E eu vou mostrar para você, funcionando, deixa eu colocar em App, na parte superior, vou rodar e vamos ver como que está o projeto.

Abriu o emulador e, perfeito, nós já temos dois produtos iguais. Temos uma banana, eu vou editar, não vai ser mais banana prata, vai ser a banana nanica e a banana nanica é mais barata, é R$ 3,99. Então, nós temos o nosso projeto funcionando como esperado.

E agora nós vamos poder entender o que são esses testes instrumentados e como que eles se aplicam dentro do nosso projeto e dentro do seu projeto. Até a próxima aula.

Testes de instrumentação - O que é um teste de instrumentação?

Bom, vamos entender agora o que é um teste instrumentado ou um teste de instrumentação. Esses testes são dependentes do framework do Android, ou seja, nós vamos ter acesso ao context, a string, a cores.

Coisas que são bem especificas sobe o framework, então, nós vamos conseguir fazer uns testes que são integrações do nosso sistema com o nosso sistema operacional.

Como, por exemplo, nós conseguimos verificar se alguma informação foi logada, se algum componente está na tela, como é o caso de um botão ou de card, e fazer ações em cima desse componente.

É como clique, scroll, aquele swap que é arrastar para o lado. Isso é uma coisa bem mais humana e bem mais perto do que o nosso usuário faria. Só que pensando nisso, por ele ser mais fidedigno às ações do usuário, ele também é mais custoso.

E o que significa esse custoso? Significa que é um teste que demora mais para ser executado, ou seja, para fazer uma ação de um fluxo inteiro, ele vai ter que, por exemplo, fazer o cadastro, fazer o login. Para criar um produto vai ter que digitar.

É uma coisa que demora um pouquinho mais e por isso anos costumamos escrever menos testes de UI. Pensando naquela pirâmide de testes, os nossos testes de instrumentação, teste de UI. Eles são os teste que estão lá no topo, que seriam mais perto da realidade do usuário, porém com maior custo.

Ao contrário dos testes de unidade que estão lá na base, eles estão bem longe dos testes de usuário, ou seja, bem longe da realidade, mas eles são bem mais rápidos para serem executados. Nós costumamos escrever mais testes de unidade.

E eu quero mostrar para vocês a aplicação dele aqui no nosso código.

Então, vamos abrir o nosso listaProdutosAdapter, eu vou clicar "Ctrl + M" e escrever LPA, listaProdutosAdapter. Perfeito. E aqui no nosso limite vamos fazer um teste bem simples.

Eu vou no nosso itemView e eu vou esconder o nosso produto. itemView.visibility vai ser igual a View.GONE, ou seja, nós vamos esconder os produtos que estão salvos. Como nós não temos nenhum produto salvo, antes mesmo de rodar, eu vou adicionar um produto, vai ser uma banana prata que custa R$ 6,99.

Deixa eu salvar e apareceu na tela, a nossa banana prata. Eu vou rodar agora com essa alteração que nós fizemos, vou clicar no botão Run no canto superior.

E a nossa banana prata sumiu, mesmo que ela esteja no banco de dados, nós não apagamos. Tanto que vamos na aba App inspection na parte inferior do nosso Android Studio.

Nós precisamos esperar um pouco para ele carregar todas as informações. Quando carrega, clicamos em Database Inspector e, depois, em produto, na coluna esquerda dessa aba. Na coluna do lado direito da aba abre o banco de dados onde temos a banana prata. Ele só não está mostrando na tela.

O que isso significa? Que nós temos um produto e ele está funcionando. Então vamos abrir o nosso teste de unidade que nós escrevemos no curso anterior.

Voltando para aba "Project", abrimos a pasta "Java", depois o source set "test", só test, não "AndroidTest", e vou apertar com o botão direito do mouse. Selecionamos no menu a opção "Run 'Tests' in 'alura.orgs'". Ele vai rodar e todos os nossos testes passaram, ou seja, ele não foi capaz de identificar que o nosso produto não está sendo listado.

Isso porque ele não tem acesso as coisas necessárias do Android e aqui que entra o nossos testes instrumentados. Por ele ter acesso, ele consegue fazer esse tipo de verificação. Então vamos entender como que nós podemos utilizar ele no nosso curso? Vamos lá.

Sobre o curso Android com Kotlin: testes instrumentados

O curso Android com Kotlin: testes instrumentados possui 85 minutos de vídeos, em um total de 50 atividades. Gostou? Conheça nossos outros cursos de Android em Mobile, ou leia nossos artigos de Mobile.

Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:

• Testes de instrumentação
• Espresso
• Destrinchando o Espresso
• Dados inconsistentes
• Testando fluxos inteiros