Teste de unidade no Flutter usando o Mocktail
Pré-requisitos:
- Saber o básico de Flutter;
- Noções básicas de testes unitários (Mock, Stub & etc);
Visão geral do Mocktail
Mocktail é uma biblioteca em feita em dart inspirada no Mockito. Seu foco principal é prover uma API simples para a criação de mocks em Dart (com null-safety) sem a necessidade de mocks manuais ou geração de código.
Então, se ele é inspirado no Mockito, por qual razão não utilizá-lo?
Se formos na página principal do Mockito, teremos a seguinte informação:
Mockito 5.0.0 supports Dart’s new null safety language feature in Dart 2.12, primarily with code generation.
To use Mockito’s generated mock classes, add a
build_runnerdependency in your package'spubspec.yamlfile, underdev_dependencies; something likebuild_runner: ^1.11.0.
Ou seja, para usar o Mockito com o null-safety ativado precisamos ou gerar os códigos, ou fazer isso manualmente.
Considerando que sempre vamos gerar os códigos (ninguém merece fazer manualmente), isso pode causar alguns incômodos ao longo do tempo, como por exemplo:
- Quando você tem muitos testes com mocks, toda vez que você atualizar algo você tera que rodar o build_runner e assim ele atualizará muitos arquivos e acaba assustando o seu time na hora de fazer aquele Code Review;
- No meu time, já tivemos problemas, como este, com o código gerado do Mockito, então comentamos alguns trechos para o CI não reclamar como paleativo.
Opinião:
Mockito é tão bom quanto, mas o Mocktail gera menos código e é mais fácil de usar. Uma evolução do Mockito para o Flutter/Dart null safety.
Hands On!
Para demonstrar o uso do mocktail, temos um projeto que utiliza a api ViaCep, um webservice gratuito e de alto desempenho para consultar Códigos de Endereçamento Postal (CEP) do Brasil.
Obs: Como o foco desse artigo é o Mocktail, não entrarei em mais detalhes de arquitetura ou boas práticas usadas no projeto. Vamos apenas ver o mocktail em ação!
No projeto temos uma feature chamada Address, que é onde nos vamos testar a chamada da API. Resumidamente nós enviamos um CEP e a API retorna mais informações sobre ele. Em caso de erro, ela retorna 400 (Bad Request).
Link do repositório: https://github.com/4rthurmonteiro/cep_tdd
Primeiro passo temos que fazer é sempre adicionar o mocktail no pubspec.yaml:
O segundo passo é criar um arquivo na pasta test, de preferência com o mesmo caminho do arquivo original, chamado address_remote_datasource_test.dart. É neste arquivo onde vamos usar o mocktail para mockar nossas dependências.
Se formos olhar o arquivo original address_remote_datasource.dart:
Conseguimos reparar que essa classe precisa da injeção do Dio, um cliente http para o dart. Sendo assim será esse cara que vamos precisar mockar em nosso teste. Por fim, temos uma função assíncrona que recebe um cep e retorna ou AddressModel, ou uma exception.
Então quando formos criar o arquivo de teste, a primeira parte será criar a classe de mock:
Para criá-la ela precisa herdar a classe Mock do mocktail e implementar a nossa dependência alvo, que nesse caso é o Dio. O nome pode ser qualquer um, mas um padrão é sempre colocar o Mock no começo e repetir o nome da classe original no final.
Após criada a classe, vamos instância-la dentro do teste e chamá-la na classe de AddressRemoteDataSourceImpl :
Agora vamos testar a função getAddress quando sucesso:
Como nossa função original utiliza o get do Dio, nós precisamos fazer o Stub dessa chamada para testarmos ela. Após isso é apenas agir e verificar se tudo ocorreu bem.
E para testarmos quando houver error:
Mesma ideia anterior, mas vamos forçar uma exception para cair no erro da função.
Conclusão
Teste limpo sem necessidade de geração de código para mockar a dependência. Apenas precisamos fazer o stub e correr pro abraço!
Encontrou algum erro no artigo ou tem alguma dúvida? Comenta aí!
