Android com Kotlin: testes de unidade e Mocks

Primeiros passos - Apresentação

Sejam bem-vindos e bem-vindas ao nosso curso de Testes de Unidade com Kotlin. Neste curso eu quero mostrar para vocês como podemos melhorar a qualidade e a segurança dos nossos aplicativos através de testes. Para isso, nós vamos criar um aplicativo chamado Orgs.

O Orgs é um gerenciador de produtos orgânicos e nele temos diversas funcionalidades, como fazer login e cadastrar um novo usuário. Além disso, nós também podemos cadastrar um novo produto, editar o produto, ver detalhes dele e excluir. Ou seja, temos muitas funcionalidades para testar.

Os pré-requisitos para este curso são: você precisa saber o que é um fragment, o que é uma activity, como funciona o Coroutines e como programar no Room para criar um banco de dados e buscar informações nele. Eu sou o Felipe Moreno e eu serei o instrutor de vocês durante este curso. Até logo.

Primeiros passos - Conhecendo o projeto Orgs

Chegou o momento de olharmos nosso projeto e entender mais ou menos como ele está funcionando, como ele está organizado. Nós temos aqui as nossas activities. As nossas activities, como vocês já sabem, representam a nossa tela, tanto as coisas que a nossa tela pode fazer, quanto o que tem na nossa tela.

Nós vamos usar a nossa activity para nos comunicarmos com o nosso repository. Podemos até ver na linha 39 que temos o repository, vou abri-lo aqui para vocês. O repository é essa camada responsável por se conectar com as diversas fontes de dados que nós teremos.

No nosso caso, a nossa fonte de dados é o Room, o nosso banco de dados. Mas pode ser que, em um projeto maior, vocês tenham mais de uma fonte de dados como, por exemplo, uma Web API ou Firebase. Então, além de salvarem no banco de dados, vocês querem avisar ao seu serviço back-end que estão salvando alguma coisa que é para ele salvar também. Vocês podem até passar o seu produto.

É para isso que acabaremos usando o repository. Ele terá todas essas fontes de dados e ele sabe como se comunicar com cada uma delas a partir de alguma ação. Além disso o teremos tanto para o nosso usuário, quanto para o nosso produto. Isso porque nós somos capazes de cadastrar um novo usuário, entrar e fazer o login, além de fazer a mesma coisa para o nosso produto.

Nós podemos cadastrar um produto, apagar um produto, ver o produto de um usuário, por exemplo. É isso que o nosso repository nos dará a capacidade. Então, abrindo o "ProdutoRepository", nós temos todas essas ações que podemos fazer. Além disso, acabaremos usando o Room, podemos ver o nosso "AppDatabase", como eu já tinha dito.

Vamos usar o Room, então temos alguns converters, além dos nossos modelos, que também são entidades. Eles representam uma tabela no nosso banco de dados. Cada uma delas, cada um desses modelos, tanto o produto quanto o usuário, têm as suas próprias regras de negócio.

Ou seja, tem coisas que precisam acontecer, que precisamos fazer essa verificação. Por exemplo, um produto, ele precisa ter um valor válido para ele ser salvo. O que é um valor válido? É um valor que seja maior do que 0 e menor do que 100, no caso. É isso o que consideramos um produto válido.

No nosso usuário, as validações são que ele precisa ter um e-mail válido e ele precisa ter uma senha válida também. Não podemos salvar um usuário que não tenha um e-mail válido e nem uma senha válida. Assim teremos um fluxo do nosso projeto.

Além disso temos algumas extension functions, como uma para formatação deste valor para a moeda real, que é a moeda brasileira. Também temos uma com formas de irmos para outras telas e outra com formas de carregarmos as nossas imagens. Tudo isso nós acabaremos utilizando dentro do nosso projeto. A ideia é conseguirmos fazer alterações e garantirmos que tudo continua funcionando. Então é isso, eu vejo vocês na próxima aula.

Primeiros passos - Por que testar o código?

Chegou o momento de entendermos o que são os testes e porque queremos testar a nossa aplicação. Eu quero que vocês imaginem uma situação comigo: imagine que estamos criando uma aplicação que é, na verdade, um skate, queremos criar uma aplicação que nos permite ir de um lugar para o outro.

Nós vamos incrementando, adicionando funcionalidades aos poucos. Primeiro teremos um skate, depois adicionamos um patinete, colocamos uma coisa onde conseguimos nos apoiar. Queremos depois colocar um banco para que você se sinta mais confortável, você quer motorizar aquilo, para que você não tenha que ficar pedalando.

Queremos também colocar mais conforto. Então olha, agora você pode se sentar relaxado dentro do seu carro e ainda assim aquela funcionalidade, que você tinha desde o skate, que é ir de um lugar para o outro, ela se mantém até o momento. Mas vamos supor que agora você quer fazer uma outra melhoria. Seu carro teve um problema e agora você precisa arrumar.

Olha o que acontece, agora temos um usuário, uma pessoa que não consegue ir de um lugar para o outro, porque o nosso carro não está funcionando, o motor acabou estragando. Como podemos evitar que a pessoa, o nosso piloto, acabe ficando triste nesta situação toda e sem o carro, sem poder ir de um lugar para o outro, que era a principal funcionalidade deste carro, desse projeto?

Nós podemos separar essa ideia, ou seja, esse carro, dentro de um contexto. Então testamos o carro antes de entregarmos para o nosso usuário. Dentro deste nosso contexto, ele pode falhar, dentro da nossa caixa, podem acontecer defeitos. Nós só não queremos que esses defeitos ocorram na mão do nosso usuário.

Nós queremos nos certificar que estamos mantendo tudo funcionando antes de entregarmos para o nosso usuário. É por isso que testamos, para garantir a qualidade do nosso código. Pensando nisso, vamos ver algumas das vantagens de testar as nossas aplicações. A primeira é a qualidade, como eu digo: você trouxe agora um produto com qualidade, que você tem aquela verificação de que está funcionando.

Nós já testamos, está tudo bonito, todas as regras do nosso negócio, tudo o que era para fazer, nós vimos que está fazendo, e ele não tem nenhum comportamento estranho. Além disso, facilita a manutenção. Mesmo que entreguemos alguma coisa com qualidade, pode ser que uma coisa ou outra passe, pode ser que usamos uma ferramenta que não testamos e conseguimos saber o porquê está falhando.

Nós podemos rodar os nossos testes e descobrir qual é o teste específico que está falhando. Além disso, a facilidade para encontrar bugs. Então, de novo, teremos um teste falhando e sabemos exatamente onde precisamos procurar, sabemos qual o método que está dando esse erro. É por isso que costumamos testar, para garantir essa facilidade de encontrar os bugs, para não sermos pegos totalmente de surpresa.

Além disso, é uma forma de documentação. O que isso significa? Que agora os nossos testes indicam o que a nossa aplicação deveria fazer. A nossa aplicação deveria dizer: o carro deveria ir de A para B. Isso deveria funcionar independentemente, está no nome do nosso método, do nosso teste.

Então qualquer pessoa que ler terá a capacidade de entender o que está acontecendo e como o nosso projeto deveria funcionar. Ele serve como uma forma de documentação. Além disso, temos um feedback instantâneo, podemos programar e saber se está funcionando ou não funcionando simplesmente rodando um teste.

Não precisamos entregar para o usuário, fazer com que ele teste, que ele tenha aquele trabalho e recebermos um feedback ruim depois de muito tempo, para só então corrigirmos. Nós conseguimos fazer isso no nosso tempo de desenvolvimento, ou seja, enquanto estamos programando. Só que também nos traz algumas desvantagens, umas poucas desvantagens que vocês vão encontrar enquanto testam.

Uma é que os testes podem ser sem sentido, vocês podem começar a testar tudo, e são coisas que não necessariamente fazem sentido vocês testarem naquele momento. Por exemplo, ferramentas externas, como seria usar uma biblioteca dentro do seu projeto e começar a testar a biblioteca em si, sendo que o seu foco deveria ser o seu projeto.

Ou, uma coisa que acontece muito, vocês estarem tentando adicionar o máximo de testes possível, só para bater uma porcentagem de testes, e adicionarem testes que não fazem muito sentido, que não agregam valor ao seu usuário. Além disso, vocês acabam precisando de mais tempo para entregar a tarefa.

Porque além de escrever o seu código, que vai para o usuário, aquele código que vocês já estão acostumados a escrever, também terão que escrever o teste para esse código. Acaba que vocês vão gastar um pouco mais de tempo para escrever esses testes. É isso, vocês agora sabem as vantagens e desvantagens de escrever testes, e estão pronto para começar. Vamos lá?

Sobre o curso Android com Kotlin: testes de unidade e Mocks

O curso Android com Kotlin: testes de unidade e Mocks possui 127 minutos de vídeos, em um total de 56 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:

• Primeiros passos
• Começando com testes de unidade
• Testes mais idiomáticos
• Utilizando Mocks
• Tipos de testes