A estrada até o 100% de cobertura no Frontend

Você sempre vai ver na comunidade de desenvolvimento de software pessoas incentivando outras a criarem testes automatizados. Metodologias como Test Driven Development (TDD) e a cultura de testar não só linhas de código, mas também todos os cenários mapeados tem sido cada vez mais difundidas.

Nos anos que tenho trabalhado como Full Stack virou algo natural. Se você não criou o teste automatizado ou não criou teste para algum cenário que foi mapeado, seu código com certeza não vai passar em um code review bem feito.

Sou programador Ruby e uma coisa que me chamou atenção desde o começo é que tudo que se faz na comunidade Ruby também é pensando em como criar um teste automatizado para aquilo. Virou algo quase como “obrigatório”.

Mas e o frontend? Não penso que são só nas empresas por onde passei, mas em geral não vejo essa cultura de testes enraizada na comunidade. Se fala muito de criar componentes e elementos visuais bacanas e claro, existem movimentos relacionados a testes e TDD mas de alguma forma não vejo como algo tão natural e “obrigatório”.

Por exemplo, no time onde eu trabalho na Resultados Digitais que é super crítico em relação a qualidade ainda é aceitável fazer entregas em produção sem que haja cobertura de front.

Mas por que testar Frontend?

Isso foi algo que sempre me perguntei. “Será que realmente precisa? Mas minha aplicação tem poucos componentes visuais e eles são simples.”

Podemos responder essa pergunta com outra: Qual o impacto se o seu usuário não conseguir fazer o que precisa?

Em geral não adianta termos APIs bonitinhas e funcionais se o nosso usuário não técnico não conseguir clicar no botão por causa de algum bug.

Dificuldade

Existe sempre um incentivo, mas ninguém vai te dizer que testar componentes de Frontend e interfaces é difícil pra caramba.

Você precisa tratar comportamentos assíncronos, criar mock de funções do próprio navegador, simular comportamentos como scroll, entre outras coisas que vão te dar muita dor de cabeça.

É nessas horas que você começa encontrar alguma desculpa para não fazer testes no Frontend.

Mindset startup?

Às vezes o fato de estar criando uma startup que precisa provar um valor de mercado rápido vira desculpa para passar por cima dos testes.

Não acho que isso seja errado em todos os casos, mas para saber se faz sentido pular os testes automatizados você precisa entender melhor o momento da sua startup e da funcionalidade que está sendo desenvolvida.

Alguns conceitos:

POC: (Prova de conceito) Estou validando se a minha proposta de solução é tecnicamente viável, se ela funciona.

Protótipo: Tecnicamente minha solução é viável, mas ainda não sei se a minha funcionalidade resolve o problema de mercado e do meu usuário.

É importante entender que tanto o POC quanto o Protótipo deveriam ser jogados fora e refeitos após provarmos o valor. Incrementar um Protótipo não é recomendado pois ele foi feito justamente com o intuito de provar alguma hipótese e principalmente no momento startup é importante que isso seja feito o mais rápido possível. Dito isso, com certeza não é uma funcionalidade que foi feita pensando em escala e qualidade.

Salvo os momentos de POC e Protótipo, pular os testes pode prejudicar muito a sua startup.

Vou dar um exemplo real que aconteceu comigo.

Além de trabalhar na RD, tenho uma startup voltada ao mercado de games, o Duality.gg. Em um lançamento de uma funcionalidade nova, acabamos quebrando o cadastro de novos usuários justamente quando estava acontecendo um evento importante. O resultado disso é que perdemos cerca de 60 cadastros, que representa hoje 10% da nossa base toda de usuários. Acham que o impacto foi grande ou pequeno?

Testes automatizados de Frontend teriam prevenido esse impacto.

Tivemos também diversos problemas no Front como vazamentos de memória, botões não clicáveis, erros estourando pro usuário. Tudo isso poderia ter sido evitado com testes.

Em geral se você está escrevendo pedaços de código reaproveitáveis, seu tempo investido em testes acaba se pagando ao longo do tempo, mesmo em uma startup.

É importante também cuidar com Protótipos que interagem com funcionalidades existentes. Nunca pule testes para essas interfaces ok?

Como eu venci as barreiras

Nunca é fácil no começo, comigo também não foi diferente. Mas após passar pelos primeiros problemas você vai entendendo como a dinâmica dos testes de Frontend funcionam. Uma hora acaba sendo tão natural quanto o próprio desenvolvimento em si.

O segredo é pensar sempre em arquitetura. Uma arquitetura bem feita e bem planejada é o que vai te dar velocidade a médio e longo prazo. Quando pensamos em Frontend, pensar na interface do seu sistema/site com componentes reaproveitáveis acaba fazendo sentido gastar mais tempo fazendo testes para esses componentes e como eles são reaproveitáveis, fica fácil de enxergar o RoI (Return of Investment) — mesmo que você ainda precise passar por uma curva de aprendizado. Os primeiros componentes a serem desenvolvidos vão demorar mais e o tempo de desenvolvimento vai diminuindo conforme você já possui uma arquitetura base mais madura e até um maior conhecimento.

Exemplo de componentes base: botão com loading, input com form error, dropdown de cidades, etc. Ter esses componentes bem escritos e bem testados com certeza vai economizar bastante tempo de desenvolvimento de outras funcionalidades.

O que testar?

Em meus projetos tenho utilizado o framework Ember.js e na estrutura básica dele os testes são divididos em:

Testes de unidade: Teste de uma função, classe ou pedaço de código de forma isolada.

Testes de integração: Teste de um componente e como ele interage com outros componentes e pedaços de tela.

Testes de aceitação: Testa o comportamento do usuário na página como um todo.

No fim todos eles são importantes e todos eles vão ajudar a prevenir problemas no seu software. Os testes de aceitação são os que demoram mais — tanto para serem desenvolvidos quanto para rodar — e geralmente repetem alguns comportamentos já testados nos testes de integração. Focar em alguns fluxos principais, desde que os outros testes cubram os demais cenários, provavelmente seja o suficiente.

Por que o 100% de cobertura é tão importante?

Não existe uma maneira de medir a cobertura de cenários, a métrica é em cima da cobertura de linhas de código. Porém, se você não possui nem a cobertura do seu código, com certeza você não está cobrindo todos os cenários possíveis. O problema disso é que o comportamento do usuário é imprevisível e sempre existe a chance do seu usuário fazer alguma ação e ocorrer um erro.

Ter cobertura de código é o mínimo para diminuir a chance desses erros acontecerem. Também é importante sempre lembrar de escrever um novo teste em caso de algum problema novo encontrado em algum cenário não previsto.

Conclusão

Não tenha medo de jogar protótipos fora após provavem seu valor. Também não tenha medo de passar por algumas barreiras para reescrever sua funcionalidade com testes automatizados.

Eu mesmo tive que jogar alguns protótipos fora antes de desenvolver minha aplicação com 100% de cobertura. Estamos num momento no Duality.gg em que os usuários têm visto valor na ferramenta e com nossas hipóteses provadas jogamos fora os protótipos e reescrevemos as funcionalidades. Com isso já conseguimos antecipar vários problemas que estariam acontecendo nas mãos dos nossos clientes.

Na Resultados Digitais tenho trabalhado bastante para mudar a cultura do time em relação ao Frontend e aos poucos o time tem conseguido enxergar o valor dos testes no Front.

Em resumo: testar tudo não é fácil, mas quando a hipótese já está provada vale muito a pena e se paga ao longo do tempo. Se a ideia é ganhar velocidade, se apoie em propostas de arquitetura em vez de pular os testes automatizados, que é um processo básico no desenvolvimento de software.