Por que não estamos fazendo testes de unidade no frontend?

[woliveiras]

Galera, estou consolidando a pesquisa sobre ferramental frontend (#1154) e postando alguns resultados enquanto escrevo o artigo/procuro apoio para trazer conteúdo sobre as pendências técnicas encontradas na pesquisa.

Recentemente postei sobre testes de unidade mostrando que 40.2% não faz testes e isso é um número meio alarmante se pensarmos no valor que testes de software agregam a um produto digital.

O @matheusml levantou a bola sobre por que será que as pessoas não estão fazendo testes em suas aplicações.

Abri essa issue para discutirmos sobre isso.

Então vamos nessa!

• Se você não faz testes, porque ainda não implementou isso?
• Se você faz testes, teve que "brigar" pra defender o valor disso em sua empresa?

Pesquisa

---

#pracegover

De 495 respostas na pesquisa sobre ferramental frontend, 40.2% não faz testes de unidade, 33.3% utiliza Jest, 11.9% utiliza Mocha e 9.1% utiliza Jasmine. Os demais estão divididos em ferramentas específicas de suas stacks, como jUnit ou elm-test.

A pergunta foi: qual ferramenta de testes você utiliza?

---

Link da postagem aqui.

[guilhermejcgois]

Ainda brigo, em quase todo sprint...

[kavalcante]

Eu faço poucos testes. Embora esteja corrigindo isso, eu ainda não me sinto "confortável" fazendo testes no front-end. Quando eu faço libs ou aplicações mais simples aqui, fazer teste vira meio automático, mas no front, sempre tenho um pouco de dificuldade.

[iramlg]

Infelizmente esse tipo de teste é totalmente subestimado em muitas empresas, principalmente start-ups, não faz parte da cultura no final (mesmo que escrevam textões sobre e seja requerido em vagas abertas).

Não posso dizer que estão errados, as entregas são sempre para ultima hora e como o front é o ultimo estágio do processo fica difícil convencer seu gerente que vc vai atrasar (mais) a entrega para implementar testes.

Quando vc está em empresas com melhor estrutura de processos e se tem um prazo melhor para desenvolvimento a implementação dos testes fica mais fácil, diria que até obrigatória.

[barraponto]

o front é o ultimo estágio do processo

mas não precisa ser, né. mocking tá aí pra isso.
quando eu fazia o design de protótipos eu fazia só o front, depois eu substituía por um backend funcional.
acredito que essa cultura de front-depois-do-sistema-pronto tá diretamente ligado com o problema de não testar.

[mosesmeirelles]

Nós utilizamos testes com Jasmine aqui na empresa, temos algumas telas com alguns cálculos bem complexos e decidimos testar isso. Nós tivemos que vender essa ideia aqui dentro, fazendo apresentações sobre os benefícios que isso pode trazer. Mas foi primeiramente implementado no back-end, muito devido a cultura que trouxemos da linguagem Python aqui.

[WandersonAlves]

Me lembro que na época do AngularJS, bower e compania (2~3 anos atrás) eu implementava BASTENTE unit tests.

Os frameworks mudaram, as coisas mudaram, e parece que cada vez mais ficou com o sentimento de "não preciso fazer unit pra isso", como se o culpado disso fosse a evolução das tecnologias. Afinal, "em um mundo facilitado como o nosso, e com certas garantias que o Typescript e o flow dão, pra quê testar?".

A primeira coisa que vem na minha mente é: "o que testar em um componente? Se ele renderiza X div? Se ele faz X logica?" e meio que fui deixando de lado.

Porém confesso que sinto falta de unit tests, só me falta ter menos "preguiça" pra criar e executar os mesmos.

Outro ponto importante é as empresas. Se você tá em um cliente que não tem essa cultura (meu caso), realmente testes unitarios ficam de lado, e mesmo que você indique o beneficio deles pro seu gestor, é capaz dele "cagar" pra o que cê fala já que tem seguir os processos da empresa/cliente.

Aqui é mais critico os testes e2e que os unitários por exemplo. Porém ainda é executado de forma errada em minha visão. Pois vão esperar o produto ficar pronto pra começar a criar os testes.

[heliomsolivas]

Eu queria muuuuuuito implementar testes no front-end, mas sempre fico perdido, não sei direito como começar. :(

[matheusml]

Criei essa enquete no twitter também pra tentar entender melhor.

O problema, pra mim, é bem grave.

[diegonvs]

Em alguns códigos mais antigos não temos testes unitários mas sempre que entra um código novo é introduzido com testes unitários. Estávamos sofrendo muito com a falta de escrita de testes unitários e de integração com muito código voltando pra refactor mas hoje o fogo foi apagado e passamos bem 😂

• Utilizamos mocha-karma com headless em algumas partes mais antigas e nas partes que estão sendo desenvolvidas mais recentemente estamos utilizando jest.
• Também temos um time que toma de conta do desenvolvimento de testes automatizados de interface <3

[WandersonAlves]

Liferay Recife é amor dms @diegonvs kkkk

[fssantos]

O @WandersonAlves resumiu o que pra mim é uma dificuldade:

A primeira coisa que vem na minha mente é: "o que testar em um componente? Se ele renderiza X div? Se ele faz X logica?" e meio que fui deixando de lado.

É difícil saber se estamos fazendo um teste útil ou não e o quanto ele vai durar no código (fazer sentido). Talvez dê aí uma boa discussão. Quem puder contribuir com um exemplo prático de um código real, eu agradeceria. Tenho bastante curiosidade.

[bernardoadc]

Na minha empresa sempre foi por pura falta de conhecimento. Encabecei essa questão e confesso que fiquei bem perdido no início. Parece fácil mas quando se põe a mão se ve que nao é tao simples, muito pq envolve toda uma cultura realmente. Não é só criar testes e pronto, ta feito - tem que cultivar ao longo do desenvolvimento como algo previsto, tanto quanto versionamento ou deploy.

Agora que já criei uma estrutura para os testes, já entendi como funciona e etc, está tudo parado por falta de apoio da gestão. Até consegui vender a importância e benefícios, mas sempre tem algo na frente pra priorizar nas sprints e pedem pra deixar isso de lado (assim como várias refatorações e débitos técnicos que estão no seu limite, que só vão receber atençao quando "estourar"). E2e nao estao nem perto de serem abordados.

Quanto à duvidas em si nos testes unitários, ainda estamos incertos se usaremos blackbox ou whitebox, se usaremos mocks ou nao (alguns pregam que isso é devido apenas em e2e, nao unitario), e quanto prolífico eles serão (explico: para alguns utilizamos o fakerjs, com todo tipo de dado sendo enviado para as funçoes, pra ver se ocorre alguma quebra ou não, o que faz com que as funçoes sejam chamadas até mais de 60x - é util ou só perda de tempo?)

[geovanisouza92]

Acho que a receita pra ter bons testes é partir do ponto de vista do usuário, do requisito, produzindo bons testes (citando o @ rauchg, "Não muitos. Principalmente integração"), para garantir que os fluxos estão cobertos.

Unitários só fazem sentido quando vc escreve libs ou regras de negócio em porções reutilizáveis, e os dados podem ser copiados de produção ou fake (o que parece fazer mais sentido).

Outra coisa muito importante é deixar de encarar testes como algo separado, à parte do projeto. Eles são parte ativa do projeto, são código que embora não seja entregue em produção (?), dão consistência e propósito pro "código de verdade".

Sobre testes atrasarem as entregas, deve-se fazer uma métrica sobre quantos bugs são causados por linha não testada, especialmente os que envolvem inputs e entradas de informações pelo usuário (quanto mais vulnerável ou menos confiabilidade se tiver nos dados de entrada, maior a chance de erros ocultos aparecerem no futuro).

Há coisas que não fazem sentido testar, como layout ou cores e textos, exceto quando esse é o requisito. Exemplo: acessibilidade ou localização.

[mvcds]

Acho que mais importante do que "porque não fazemos unitarios" é "porque não escrevemos testes".

Unitários, pelo menos pra mim, poderiam focar em coisas dificeis (algoritimos raramente feitos no front) ou complexas de implementar, onde existem
muitas váriações (tipo cadastro de usuários), do contrário a gente cai no risco de testar por testar.

Eu tava com uma ideia fixa de testar as coisas guiadas pela necessidades de negócio, então acabava priorizando os de integração pro front, sem deixar o app tocar banco e essas paradas que não tenho controle (através de mocks e requests falsificados). Mas há um tempo vi que um time da ThoughtWorks de São Paulo faz algo que talvez, pro front, seja mais interessante: guiar esses mesmos testes de integração segundo o que se espera que os usuários façam.

[diegohaz]

Nas empresas onde eu trabalhei, tanto no Brasil quanto fora, o que acontecia é que, no início do projeto, sobretudo antes do lançamento, tudo era testado bonitinho.

Depois de lançado, as demandas aumentavam, os prazos diminuíam, e as regras de negócio mudavam com frequência, o que é natural. O resultado é que os testes (não só unitários) iam diminuindo.

Conforme o tempo foi passando, eu também fui dando menos valor a testes unitários no front end. Eu costumava testar cada parte do código, inclusive componentes React extremamente simples.

Com o tempo, eu fui adotando uma abordagem, ao meu ver, mais efetiva. Comecei a fazer mais testes de integração que unitários. Parei de testar componentes e comecei a abstrair as complexidades dos componentes em pequenos utils, esses, sim, devidamente testados.

Essa, na minha opinião, é a melhor combinação entre agilidade e confiabilidade de código. O próximo passo é fazer mais testes end to end.

[mvcds]

MAs @diegohaz, e2e não pode gerar muito ruido?

No sentido de que pra ser um e2e de verdade, até onde entendo, o sistema teria que ser o mais real possivel, ai lá se vai o controle que temos sobre o teste.

---

Acho que esse lance de queremos testar tudo no começo e dps irmos entendendo que nem tudo é necessário testar, é total normal, parte da gente entendender nossas ferramentas. Sei lá.

[klarkc]

Estou com o @ninetails , o problema é mais embaixo, diria até que em nível de processo e de como se escreve código e se planeja o desenvolvimento. Em muitos cenários, agile virou "desculpa" para cuspir software mal acabado e defeituoso.

A falta de uma metodologia clara de desenvolvimento, a falta de requisitos e critérios de aceitação nas histórias, a falta de tradução dos requisitos em testes, tudo isso é uma realidade bem próxima de startup's que focam muito mais na entrega do que no valor gerado. Se esquecem completamente que entregar algo com débito técnico é como tomar um empréstimo a juros altíssimos. Nunca passam para o próximo estágio do produto porque não têm como evoluir o produto pelo alto custo que eles mesmos criaram.

Depois dizem que isso é ágil. Bom se vc entrega um MVP q não consegue evoluir, por ser muito caro, onde está o valor nisso?

[matheusml]

Saiu o resultado da enquete:

Edit:
Não tiveram respostas relevantes pro campo 'Outro'

[guilhermejcgois]

@matheusml não rola de trazer as respostas do "Outro" também?

[angelosds]

Onde trabalho, o processo de frontend ainda é bem defasado e mesmo no backend não há a cultura de testes. Recentemente, em uma conversa com meu gestor, conseguimos implementar alguns testes em backend, está longe do ideal mas já é um começo.

[LuanFreitas]

Aqui onde trabalho vamos começar nossa primeira implementação de testes no próximo projeto, que envolverá Vue js. Mas eu noto que a maioria das empresas não incentivam isso e a nossa própria comunidade deveria continuar pregando muito esse conceito pra que venha a se tornar uma coisa imprescindível.

[linconkusunoki]

Eu comecei escrever bastante depois que fiz o curso JS com TDD do @willianjusten
Bom saber que o Jest está com popularidade em alta, estou usando ele aqui é muito bom :)
Uma coisa que senti dificuldade foi testar algumas coisas no Redux trabalhando com Containers
Aqui onde trabalho temos uma cultura forte para incentivo a testes é bem legal 👍

[mosesmeirelles]

Algo interessante para disseminar a cultura de escrever com testes, é a realização de Dojos com a equipe. Pode ser a implementação de atividades simples, mas no decorrer da atividade ir expondo a importância de testes para que o próximo desenvolvedor consiga fazer as alterações sem quebrar o que já tinha. Fora que é bem divertido e dissemina vários aprendizados :)

[ninetails]

Aproveitando a deixa, outra coisa que eu estou percebendo é que mesmo implementando testes, não vejo fronts implementando bons testes. Já peguei também muita coisa na empresa que estou sobre testes usando beforeAll por exemplo, ou seja, testes interdependentes. Teve até um outro projeto onde eu tentei usar um only e outros testes quebravam.

Estou bem pessimista sobre a falta de cultura e importância sobre testes.

+1 pra Dojos, tentei implementar Coding Dojo no último lugar onde trabalhei, foi bem promissor em relação a ensinar a galera a testar e ter empatia pelo próximo.

[mahenrique94]

Testes hoje em dia são muito importantes, hoje não vejo mais um projeto sem testes, é essencial, desde que sejam bem escritos e abordam aquilo que precisa ser abordado.

Sobre o fato de não saberem testar, o curso JS com TDD do @willianjusten é excelente, recomendo para quem ainda não faz testes.

Tanto no meu blog quanto no meu canal estou para escrever artigos/vídeos falando sobre testes, para tentar ajudar ainda mais e mostrar o porque de testes.

[klarkc]

@ninetails alinha justamente com o resultado da enquete, muita gente nem sabe o que é teste unitário pra começo de conversa, +1 para Dojos, mas o que vai ensinar mesmo é por a mão na massa e dar oportunidade para os devs desenvolverem da forma correta, e principalmente, sem pressão de tempo e sim de qualidade. E sim isso custa caro, desenvolver software em geral custa caro, se vc quer validar uma ideia prototipe, e só então desenvolva.

[tcelestino]

Depois da última experiência, passei a enxergar os testes como algo primordial. Acredito que vai da cultura da empresa que está atuando e de como você vai lidar com os "prazos" que te passam.

[FlaviaTaynara]

Eu entendo os beneficios do Front end teste para o projeto,
mas quais seriam os beneficios olhando do ponto de vista da empresa?

[wilsongomes-swe]

Menos bug, menos manutenção, menos devs necessários com sustentação, menos stress dos devs, menos bugs em produção, menos clientes tomando tela quebrando na cara, menos horas tentando entender onde quebrou, menos chance de uma nova feature quebrar outros pontos, menos necessidade de QA manual, menos tempo para evolução, menos tempo para manutenções necessárias...

É o mesmo caso de escrever bons códigos que outros devs leiam fácil, e escrever um código sujo que apenas "roda", a primeiro momento na entrega a diferença é: o código "sujo" e de quaquer jeito sai bem mais rápido no primeiro momento, mas no longo prazo os outros devs vão gastar muito mais tempo para entender, vai ter muito mais bugs, a manutenção será bem mais morosa.

No fim é, vc desenvole com uns 30% a mais de tempo, mas economiza uns 90% de tempo no futuro, tempo seu e de outros devsm e consequentemente vc economiza R$ para empresa e ajuda ela a entregar mais.

[ninetails]

Assim como tipagem, testes auxiliam encontrando erros triviais no código e no produto.

NASA lost its $125-million Mars Climate Orbiter because spacecraft engineers failed to convert from English to metric measurements
fonte: https://www.latimes.com/archives/la-xpm-1999-oct-01-mn-17288-story.html
outras histórias: https://smartbear.com/blog/software-bug-cost/

Claro que to indo pro hipotético pq não achei mais exemplos rs

Mas imagine trabalhar num banco e ter uma conta errada que seja num programa indo pra produção?

Ou você tem um ecommerce mas ninguém consegue clicar no botão de comprar?

E digamos que isso funcionava mas parou de funcionar por algo adicionado num outro momento em um outro lugar do código onde parecia ser simples a alteração e parecia que não tinha nada a ver?

Vai jogar a responsabilidade pro QA? (Deixe o QA testar funcionalidade, não código!)

Vai depender apenas de observabilidade (logs) pra encontrar esses erros?

O custo é mais barato quando feito durante o desenvolvimento do que encontrar um erro em produção, afetando usuários e tendo que "apagar incêndio" pra corrigir, além de ter que alocar desenvolvedor que sofre pela interrupção pois certamente estava já atarefado em alguma outra entrega de valor.

Ter testes unitários não vai prevenir que seu produto não tenha erros, isso é impossível. Mas vai minimizar o risco de interromper um desenvolvedor no melhor caso; ou perder milhões no pior caso.

[tcelestino]

Muita gente está deixando de aprender o básico (no meu ponto de vista, testes, seja de unidade, integração, etc... faz parte do aprendizado de um profissional) e vejo que as escolas/cursos de desenvolvimento não abrange nessa parte do desenvolvimento, nem as coisas básicas.

Também existem empresas que não ligam pra isso, porque o resultado final é entregar valor para empresa, independente da forma que vai ser entregue.

[FlaviaTaynara]

concordo contigo, o tempo de teste as vezes é visto como uma perca de tempo, pois o desenvolvedor poderia estar trabalhando em algo mais "serio ".

[klarkc]

Um tempo atrás eu escrevi esse post no meu blog pessoal, justamente falando sobre qualidade em startups e algumas saídas pra não cair nessa cilada de desenvolver sem testes. É bem curto, mas sintetiza bem o que eu penso sobre o assunto. Deixando aqui para quem achar útil.

[lucasRMZappy]

Sinceramente, eu sei fazer testes no frontend, porem ja trabalhei em dezenas de empresa, e literalmente so uma (uma gigante inclusive) pedia teste unitario, mas mesmo assim não era tão obrigatorio, na grande parte era melhorar testes ja existentes, porem havia diversos arquivos sem testes.
E muitos que contiam testes, era somente uma implementação super basica que não fazia literalmente nada so para falar que tem um arquivo .test.js ou um monte de coisa mockada que na minha opnião não testava é nada.

Mas mesmo tendo o conhecimento, eu ainda não sinto a necessidade dos testes. Sempre vejo todo mundo falando que tem que fazer testes unitarios, que são importantes e etc, porem nunca vejo ninguem falando o PORQUE eles são importantes.

Sinto um pouco de comportamento de manada, não falando que fazer tal teste seja errado, porem literalmente todos que confrotei do porque consideravel testes unitarios no frontend importantes, literalmente ninguem sabia responder, os mais afiados davam respostas vagas e genericas.

Ainda espero uma explicação gorda e bem tecnica, que é oque o mercado e tecnologia precisa, para justificar tempo de desenvolvimento.