Fala Devs, como esto?

Hoje vamos abordar um assunto um tanto quanto polmico, amado por alguns odiado por outros, mas que muito importante, se voc no tem miopia e prestou ateno no ttulo deste artigo j deve imaginar que iremos falar sobre Testes.

Sei que muitos desenvolvedores, me incluo nessa, odeiam fazer o famoso teste unitrios, alguns nem tem ideia do que se trata, mas tentarei resumir de uma maneira bastante simplificada.

Testes Unitrios

Basicamente existem vrios tipos de testes (testes de performance, teste funcional, teste de integrao etc.) ns programadores estamos muito acostumados a realizar o teste de unidade de uma maneira muito simplificada trata de um teste isolado a um componente ou classe que o desenvolvedor alterou ou criou, ou seja, voc vai testar isoladamente aquilo que voc mexeu, no se preocupando muito com o restante do sistema, se o que voc fez quebrou o que j funcionava (esse teste ser realizado na etapa de teste de integrao).

Claro que todos sabemos que testar o que desenvolvemos muito importante, mas testar manualmente um milho de cenrios humanamente impossvel desta maneira graas a evoluo da tecnologia hoje conseguimos criar testes de maneira automatizadas, desta forma conseguimos testar vrios cenrios.

Como exemplo vamos criar um contador (que nem o do projeto de exemplo do exemplo do flutter) mas trabalharemos com o mobX, os testes no dependem exclusivamente do mobx, poderamos usar BLOC ou qualquer outra coisa, mas vale ressaltar que de suma importncia comearmos a separar a lgica do design, desta maneira nossos testes ficaram muito mais fceis de se escrever e muito mais organizados.

Desta forma teremos uma controller com dois mtodos para incrementar e decrementar

Assim vamos criar nosso arquivo para testar se essa controller est fazendo o que realmente esperamos, para criar o arquivo de teste basta criar um arquivo na pasta test com o nome count_test.dart, muito importante que o arquivo tenha o sufixo _test.

Se trata de um arquivo com cdigo dart normal, temos que ter mtodo main(), pois nele que iremos adicionar os testes utilizando atravs da chamada test() que espera uma breve descrio do que se trata o teste e uma funo de como iremos testar.

Nesse caso criei uma instncia do HomeController e testei se o valor de count igual a 0 (que seu valor inicial) com a funo expect. Logo em seguido executei o mtodo add(), ento esperamos que ele incremente 1 ao count, aps realizamos o teste count verificando se ele vale 1. Desta maneira conseguimos executar o teste utilizando o comando flutter teste e ele ir me retornar se teve erro em algum teste.

VS CODE

Para quem utiliza o Visual Studio Code l conseguimos instalar o plugin de testes, desta maneira conseguimos executar os testes apenas clicando em Run/Debug.

E conseguimos at Debugar nosso cdigo executando linha a linha e verificar o que est ocorrendo em tempo de execuo.

Mocks!?

Praticamente todos os sistemas existentes fazem algum tipo de integrao com webservices ou banco de dados, e as vezes precisamos testar classes que dependem de buscar dados dessa integrao, testar essas classes se tornam inconvenientes por algumas razes.

Chamar webservices ou banco de dados on the line diminui a velocidade de execuo dos testes.

Um teste pode comear a falhar devido a instabilidades do webservice ou banco de dados e eles podem trazer resultados inesperados, isso conhecido como teste superficial.

difcil testar todos os cenrios possveis de sucesso e falha usando um servio da Web ou banco de dados ao vivo.

Portanto ao invs de depender de servios web ou banco de dados on the line mais prudente mockar essas dependncias, os mocks permitem voc simular essas dependncias e retornar um valor especfico.

Para fazer isso temos um package do flutter que se chama mockito, basta adicion-lo em seu pubspec como dependncia de desenvolvimento(creio que ele j venha por padro).

IoC e DI

Para conseguirmos falar sobre MOCK muito importante falarmos de Injeo de Dependncia(DI) e Inverso de Controles (IoC), tem um vdeo muito interessante no canal da Flutterando.

Esses so temas que eu poderia escrever vrios artigos a respeito, mas como no o objetivo deste artigo tentarei ser sucinto. Lembrando que esses conceitos valem para qualquer linguagem e no especificamente o Flutter.

Suponha que eu tenha uma service que ir chamar minha classe de repository, ento teoricamente basta eu criar uma varivel do tipo AccountRepository e instanci-la certo? Tudo muito lindo e funcionando, mas utilizando essa abordagem de deixar minha service com a responsabilidade de iniciar o AccountRepository teramos alguns problemas.

Perceba que a classe AccountRepository precisa da urlBase para poder realizar a conexo com a API, agora vamos imaginar que essa URL se alterou para http://urlapi2.com, Oxe!? s eu ir na AccountService e alterar, no? Certo, isso iria funcionar, mas vamos nos perguntar, o que a classe de repositrio tem a ver com a classe de servio? NADA!(ou pelo menos no devia) Inclusive criamos o aplicativo separando em services, repositories, controllers justamente por causa disso, cada camada tem sua responsabilidade.

Nesse caso fcil modificar apenas um service, agora imagina se tivssemos 30 services. E outra, a classe de servio sabe que a classe de repositrio necessita de uma url e isso no justo j que a responsabilidade da classe de servio apenas aplicar as regras de negocio e chamar a repositrio, que essa sim por sua vez teria a necessidade de se responsabilizar de integrar com a API, ento nesse exemplo vemos um alto acoplamento nesse cdigo.

E outro problema mais profundo, que est relacionado com o ttulo deste artigo, como faramos, por exemplo, para fazer um teste com minha classe servio e mockar minha dependncia com o repositrio? Simplesmente no iremos conseguir, pois a reponsabilidade de construir o repositrio est a cargo do meu service.

aqui que entra a inverso de controle (IoC), vamos literalmente inverter os controles em meu service, em vez de deixarmos a responsabilidade da criao do repositrio na minha service vamos j conceder ao service minha repository montada, deste jeito vamos injetar as dependncias que a service necessita e ai que entra a magica da injeo de dependncias (DI).

Essa uma forma, e uma das mais populares, de utilizar injeo de dependncia, o Constructor Injection, ou seja, injetamos uma dependncia de uma classe atravs do construtor dessa classe.

H muitas ferramentas que nos auxiliam na criao de projetos com injeo de dependncias e um deles adivinha qual ? Isso mesmo, o Flutter Modular, basta adicion-la no meu app_module.

Na Injeo de Dependncias existem vrios padres que podemos utilizar na DI, um deles o padro por contrato utilizando interfaces, eu sei no dart no tenho interfaces, mas conseguimos simular uma interface e funciona muito bem tambm, eu particularmente gosto de me organizar criando uma pasta interfaces dentro de cada camada e l teremos nossos arquivos de interfaces.

Para criarmos interfaces no DART (como ele no tem interface) criamos utilizando classes abstratas, contendo todos os contratos de mtodos que ter na minha classe concreta.

Desta forma basta eu implementar a classe abstrata na minha classe concreta

E l na minha classe de servio que chamava a AccountRepository eu no preciso mais chamar ela diretamente, posso trocar minha dependncia apontando para interface, dessa maneira eu posso injetar uma classe MOCKADA quando for fazer os testes.

Uf! Assim conseguimos resumir bem o que IoC e DI. E no se esquea! se ficou alguma dvida, deixe um comentrio.

MOCK

Agora voltando para nosso assunto principal, vamos criar uma classe fake que retornara nossos dados mockados.

Uma outra forma de mockarmos um dado importar os json na pasta assets

Precisamos tambm liberar o acesso aos arquivos l no pubspec.yaml

E l na minha classe de Mock carregamos esse arquivo e utilizamos o mtodo fromJson() da minha Model para construir o resultado.

Desta forma deixamos nosso Mock mais fiel ao repositrio original

L no modulo precisamos injetar a dependncia do repositrio. Desta maneira fica a responsabilidade de dizer se ele vai utilizar o Repository ou o Mock a quem for utilizar o service.

setUp

Agora que criamos as injees de dependncias podemos utilizar na prtica, para isso nos testes no DART temos um mtodo que chama setUp() que serve para inicializarmos os atributos dos meus testes, no exemplo a seguir vamos criar uma Controller (PayslipController) e vamos injetar a PayslipService e o mock da PayslipRepository.

Dessa maneira conseguimos injetar todas as dependncias necessria para utilizar a PayslipController, fcil n? Mas tudo pode ficar mais fcil ainda com o Flutter Modular, para isso eu posso utilizar o mtodo initModule() que j me traz todas as dependncias do projeto, e para trocar a instancia o repositrio para a classe de mock basta eu utilizar o atributo changeBinds.

Testes de Widgets

No pacote flutter_test temos uma opo bastante legal que no vemos em todos os frameworks por ae, que a possibilidade de testarmos os widgets para isso basta utilizarmos a funo testWidgets() e podemos utilizar da seguinte forma. (Este o exemplo do contador)

Na primeira linha do teste ele utiliza o pumpWidget() para inicializar o MyApp() que a tela principal do APP, em seguida eu verifico se eu encontro um widget com o texto o texto 0 na tela e se no h nenhum widget com o texto 1.

Logo em seguida eu o mando procurar um widget que contenha um cone de adicionar (+) e logo em seguida eu peo para ele pressionar tap o boto.

Eu uso o pump() para aguardar ele renderizar a tela com seu novo estado e fao as verificaes novamente, verifica se no existe um widget com o valor 0 (findsNothing) e se eu encontro um widget com valor 1 (findsOneWidget).

Thats all folks!. De uma maneira bem resumida isso que conseguimos fazer utilizando a biblioteca de testes do Flutter, pode ser um pouco trabalhoso no incio mas garanto que isso trar muitos benefcios conforme o projeto vai crescendo.

Entre em nosso discord para interagir com a comunidade: https://discord.com/invite/flutterbrasil
https://linktr.ee/flutterbrasil