O que são Testes Unitários e como implementar em JavaScript?

[@DevPleno]

Entregue aplicações web profissionais com autonomia e destrave a sua carreira para salários acima de 10 mil reais. Garanta sua vaga no treinamento Fullstack Master: go.devpleno.com/fsm

[@diedienifer]

Vídeo excelente! Sua didática é altamente eficaz e facilmente compreensível.

[@DevPleno]

Muito obrigado!

[@MatheusGustavoMGP]

Bacana demais,fiz videos tambem mostrando numa aplicação real os testes unitarios e e2e ,numa aplicação so com nodejs e tambem outra com nodejs + typescript

[@gabrielfigueiredo7344]

Parabéns pelo vídeo! Ótima didática sobre um assunto pouco aprofundado no youtube BR!

[@DevPleno]

Muito obrigado! :)

[@adrianobaza]

Show de aula! Parabéns e obrigado 🤝

[@DevPleno]

Eu que agradeço o comentário e feedback :)

[@nomadealex]

Que foda!!! Claramente meus testes vão precisar de testes kkkkkk Muito bom, cara!

[@DevPleno]

hehehehe muito obrigado!

[@gafanhotoaprendiz358]

kkkkkkkkkkkkkkkkkkkkkkkkkk

[@rafaellaube]

Excelente vídeo! Deu pra ter uma ótima noção do que o Jest é capaz e também conhecer um pouco mais sobre testes unitários. Parabéns pelo conteúdo, abraço 😁!

[@anselmonascimento3324]

Muito bom aprendendo 1% todos os dias.

[@DevPleno]

Estamos juntos!

[@edufgh6266]

vc bem que podia fazer um video monstrando como isolar dependências em class.

[@grandesfrases5021]

muito bom a aula, parabéns

[@DevPleno]

Muito obrigado :)

[@antonio_cds]

O tema de mockar o driver é interessante!

[@wevertonj]

Vídeo excelente, gostei muito da explicação. Só me incomodou um pouco a modificação de uma variável global no exemplo. Acho meio arriscado este tipo de manipulação. Daria para criar um parâmetro opcional na função com uma condicional para usar o valor passado ou o Date.now() caso o parâmetro fosse vazio, assim a função usaria o Date.now() em produção e estaria aberta para receber um valor personalizado no ambiente de testes, com o mesmo resultado do apresentado no exemplo, mas sem o risco que a alteração de variáveis globais trazem.

[@DevPleno]

No caso do ambiente de execução de testes não tem problema. Pois o processo (processo de execução mesmo) de testes vai ser diferente do seu em produção.

[@willianferreira1634]

Eu já fiz esse tipo de coisa pra resolver um problema que tive, e cara, não é uma boa opção... 1 - O Coverage do teu teste nunca vai considerar o caso real, pois vai considerar apenas o teu parâmetro, pois a ideia é que você teste tudo da sua função, assim tu acaba criando uma branch e essa branch não vai ser testada 2 - É gambiarra. Só faria sentido se você realmente fosse usar a função dessa maneira, com um parâmetro opcional, mas fazer só pra testes... é gambi das braba 3 - o DevPleno deu só um exemplo... Mas o Jest tem uma ferramente pra esse tipo de problema que é o useFakeTimers (específico pra tempo), mas em alguns casos, realmente não tem então alterar o global é a saída. Se tiver que usar em mais testes o global faz a alteração dentro do beforeEach 4 - Como o DevPleno disse não tem problema alterar uma global, já que esses casos são somente relacionados aos testes, não impacta em nada no projeto. A única coisa que se deve ter cuidado, é se caso outro teste usa e esse valor precisa ser diferente, maaaas se tu fizer apenas dentro do método do teste, ele não vai alterar pro restante, pois cada teste executa em paralelo. Ah não ser que você use o beforeEach... Mas se teus testes usarem esse valor diferente, não faz sentido usar o beforeEach.

[@wevertonj]

@@willianferreira1634 Particularmente, tento manter o mesmo design de aplicação nas diferentes linguagens que trabalho, talvez por isso eu tenha estranhado a modificação direta de globais, mas a uma das melhores coisas de ser desenvolvedor é a infinidade de abordagens que podem ser escolhidas para fazer a mesma coisa, então tá tudo certo. Só discordo de ser gambiarra. Esta abordagem em testes unitários de passar como parâmetro códigos externos, além de facilitar os testes, expande as possibilidades de uso do mesmo, tornando-o mais genérico. A partir daqui, mesmo que não precise desta abertura que o código passou a me oferecer neste projeto, esta não dependência de uma fonte específica vai me permitir reutilizar ele em outros projetos que precisem do mesmo processamento de dados do mesmo tipo, mesmo que a fonte externa seja outra. Obviamente que aqui não estamos falando de funções super simples como a abordada no vídeo, mantive o mesmo exemplo para ficarmos na mesma página, mas o meu ponto não era a função em si, mas sim o uso de variáveis globais.

[@willianferreira1634]

@@wevertonj mas ai entra o que eu falei, se você realmente vai usar a função de outra, e esta deixando genérica por isso faz sentido. Mas precisa ter em mente que se fizer isso só pra testes ele nunca vai cobrir a tua real função, que é o caso que eu citei das branchs e quanto mais funções tiver esse parâmetro pra testar, menor é o coverage...

[@paulolb9571]

Muito bom o conteúdo.

[@DevPleno]

Muito obrigado :)

[@rede_neural]

Os nomes dessas funções são MUITO boas kkkk o js inteiro devia ser auto explicativo assim

[@DevPleno]

hehehehe

[@limaand2009]

Jest consegue exportar um relatório geral com todos testes executados?

[@DevPleno]

Sim senhor

[@limaand2009]

@@DevPleno você pode demonstrar ou indicar algum material ?

[@duduskateboarddudu]

Top HIGH quality software

[@DhenysonJhean]

Sempre testei usando console.log, nem que fosse preciso copiar a função para um lugar isolado do projeto e testar apenas ela. Ainda senti muito bem os ganhos de usar esses testes, pois parece que se eu levar 10h programando algo, vou passar mais 15h fazendo testes... e usando typescript pronto... projeto de 10h vai levar 36h, sei que tudo isso é para qualidade e typescript ja uso, mas esse teste me pareceu complexo demais para o resultado.

[@hildegarmedina]

Uma vez trabalhei em um projeto que tinha testes unitários, eles deixaram os testes unitários junto com Git, e ao momento de eu tentar fazer um git push, se o código tinha problema, ele não me deixaba fazer o upload. 🤔

[@wevertonj]

Entendo a sua visão, trabalhei por 6 anos usando apenas o console.log para testes e não via motivos para usar testes unitários, mas agora que estou trabalhando com eles, percebo que é muito mais rápido para identificar problemas no código com eles, o que acaba compensando o uso de testes unitários. Em um primeiro momento, você realmente demora mais tempo para finalizar o projeto com testes unitários, mas com a prática, o tempo de desenvolvimento reduz significativamente. Um projeto que demoraria 10h para ser desenvolvido passa a levar 7h com testes unitários. Eu sei que parece contra intuitivo, mas além da consistência de código, eles realmente trazem um ganho de performance.

[@willianferreira1634]

Respondi isso em outro comentário, mas vou colar aqui. Os intuitos são diferentes, teste no console é na hora do desenvolvimento (tmb n é o ideal, pois tem ferramentas pra debugar, mas a gente sabe que é mais fácil). O teste unitário, não é pra voce VER se ta funcionando... É pra voce GARANTIR que aquilo ta funcionando. Esse hook de não deixar fazer commit sem fazer os testes é muito importante, para que o dev não esqueça, ou que ele realmente faça o teste passar... De fato fazer testes unitários faz o desenvolvimento ser mais longo, porém ajuda no futuro...