Quando testar um componente React?

SIM, VOCÊ ENTENDEU ERRADO. DEIXA EU TE EXPLICAR. 🚀

Primeiro, sim, a internet tá cheia de LIXO. Quase todo teste automatizado por aí é só um unit test burro, quase sem valor algum. Mas mesmo esses testes TÊM SUA UTILIDADE.

Mas olha, isso aqui não é um tutorial sobre como escrever testes eficazes. É só um recado humilde pra convencer um jovem programador (ou não tão jovem) que testes são EXTREMAMENTE ÚTEIS. Então, relaxa, não vou te encher de regras ou boas práticas. Só quero que você entenda o PODER que testes automatizados têm de SALVAR SUA VIDA (ou pelo menos sua sanidade).

Pega o exemplo da sidebar que você mencionou. Claro, você pode abrir a aplicação e ver se tá tudo certo. Isso funciona ENQUANTO SEU APP É PEQUENO. Mas quando você tiver MILHARES DE COMPONENTES, abrir tudo e ficar clicando manualmente é UM DESPERDÍCIO DE TEMPO ABSURDO.

E tem mais: uma mudança num componente pode QUEBRAR OUTRO COMPONENTE que você nem lembrava que existia. Testes automatizados CAPTURAM ISSO.

Eles são como GUARD-RAILS numa estrada. Você ainda precisa dirigir com cuidado, usar cinto de segurança e ter um carro com airbag, mas os guard-rails estão lá pra evitar CATÁSTROFES.

ENTÃO, QUANDO ESCREVER TESTES?

ASSIM QUE TERMINAR O COMPONENTE é uma boa resposta.

Mas talvez uma resposta AINDA MELHOR seja: ASSIM QUE ENCONTRAR UM BUG. No mínimo, escreva um teste pra garantir que aquele bug NUNCA MAIS ACONTEÇA. Testes automatizados NÃO SERVEM para evitar bugs. Testes:

DOCUMENTAM como interagir com componentes.

FACILITAM REFATORAÇÕES — você pode mudar o código à vontade, sabendo que os testes vão te avisar se quebrou algo.

ECONOMIZAM MUITO TEMPO a longo prazo.

Claro, no começo pode parecer que você tá gastando mais tempo escrevendo testes do que codando. Mas isso é INVESTIMENTO. Quando seu app crescer, você vai agradecer por ter esses GUARD-RAILS te protegendo.

O PONTO CRUCIAL

O VERDADEIRO PROBLEMA é quando bugs acontecem em produção e você NÃO FAZ IDEIA DO PORQUÊ. Aí, meu amigo, é PERDA DE TEMPO GIGANTE. Debuggar sem testes é como procurar uma agulha num palheiro. TESTES SÃO DETECTORES DE METAL. Eles mostram ONDE as coisas quebraram, O QUE quebrou e COMO quebrou. Ou pelo menos deveriam.

Depois de noites mal dormidas perseguindo bugs que NUNCA DEVERIAM TER CHEGADO TÃO LONGE, você percebe: "Eu deveria ter escrito mais testes e testes melhores."

Se você não tem isso, vai passar horas (ou semanas) tentando descobrir o que deu errado.

ENTÃO, RECAPITULANDO:

Testes automatizados são GUARD-RAILS — não servem pra evitar acidentes (bugs), mas reduzem as chances de um acidente (bug) causar um estrago FORA DE CONTROLE.

Escreva testes ASSIM QUE TERMINAR O COMPONENTE e ASSIM QUE ENCONTRAR UM BUG.

Eles DOCUMENTAM, FACILITAM REFATORAÇÕES, e ECONOMIZAM TEMPO.

NÃO CAIA NA ARMADILHA DE ACHAR QUE TESTES SÃO INÚTEIS. Eles são ESSENCIAIS pra qualquer projeto que pretenda crescer sem virar um pesadelo.

Agora, VAI LÁ. Escolhe um componente, escreve um teste, e quando você perceber que dá pra refatorar sem medo, quando perceber que tá gastando mais tempo escrevendo testes do que programando, como seu colega aqui, você vai entender que:

Gastar tempo escrevendo testes automatizados é infinitamente melhor do que gastar tempo debugando código pra descobrir por que as coisas não funcionam. ISSO SIM É TEMPO PERDIDO.

Um abraço e bons estudos!

Meus 2 cents:

Sigo o relator @clacerda e acrescento: testes facilitam a vida a longo prazo. Daqui 1 ano, aquela rotina que voce nem faz ideia do porque existe, o teste pelo menos garante que esta funcionando como planejado inicialmente.

Alem disso, em projetos que tem participacao de diversas pessoas, os testes ajudam os devs mais recentes (e que nao tem ainda tanta intimidade com o projeto) a entender o funcionamento de certas coisas, ainda que nao tao bem documentadas.

Digo mais: ja aconteceu mais de uma vez de pegar uma lib sem documentacao adequada mas que tinha alguns testes - eh o bastou para analisar como era esperada a interacao com ela.

Enfim, testes sao um saco - de fato necessitam de investimento de tempo. Mas em projetos grandes ou que vao ter muitas maos interagindo, sao teu salva-vidas.

Eu não tenho muita experiência em testes ainda, mas posso afirmar algumas coisas: Teste, teste e teste para não se arrepender.

Assistindo a vídeos no YouTube, vi muitos testes verificando se uma sidebar foi renderizada corretamente e se os elementos estavam na tela. Mas isso não é algo que eu posso simplesmente abrir a aplicação e conferir na hora?

Não necessariamente. Se for algo seu e funcionar, talvez não precise. Mas se for algo para algum usuário final usar, é necessário pois navegadores tem questões de compatibilidades e etc... O Safari então é um pé no saco... Então é bom se certificar que esta tudo renderizando corretamente em vários cenários.

Outro ponto é que testes tem de ser estratégicos. Não é necessário testar absolutamente tudo, apenas aquilo que realmente importa. Como definir isso? Eu sinceramente vou por tato e pela a pouca experiência que tenha, mas no geral, com muito estudo, você irá encontrar esta resposta.

Teste, nunca deixe de testar. As vezes os bugs passam no teste, ai você refina o teste e testa o teste também. Não esqueça que a dor de cabeça é maior uma vez que o usuário final acessa algo bugado...

Olá! Também estou começando agora nesse mundo automatizado, e ontem mesmo vi um vídeo sobre isso do Diego da RocketSeat: https://www.youtube.com/watch?v=N6Yvi4lPqxs&t=97s e ele fala sobre teste de componente.

Espero que te ajude.

Quando ele existir!
Se tu criou um componente provavelmente ele precisa ser testado nem que seja um simples snapshot.