[Dúvida] Por que fazer testes front-end?

Teste unitário é um único teste, faça testes de unidade.

Se é teste de unidade, deve testar cada unidade, seja ela visual ou não.

Também deve fazer testes de integração.

A extensão do quanto você deve testar depende do projeto e a experiencia é que determinará isso. Quem está começando provavelmente fará errado. EU faço até hoje. Por isso é importante ter pessoas experientes nos auxiliando em todo aprendizado, para não aprender errado e sempre fazer errado. Eu tive a sorte de aprender muito sobre computação com gente muito boa, com o STack Overflow, etc. Infelizmente testes não tive muito essa oportunidade, quase todo material que tem por aí não ajuda muito, eles ensinam os mecanismos, mas não o uso real e não tenho que possa me corrigir. Por sorte com grande experiência no resto e bom discernimento estou aprendendo cada vez mais fazer melhor, mas demora mais, é mais sofrido. Por isso não faço sempre que deveria.

Testes visuais devem(riam) ser automatizados também, por isso eles são um pouco mais trabalhosos de fazer e eu admito que não costumo fazer (até porque não costumo trabalhar com front também), se você não automatizar, em algumas semanas, dentro de um cenário mais comum, você terá gasto mais tempo fazendo manualmente do que automatizando.

Dependendo do caso testes manuais podem ser bem interessantes, quando está testando a UX e não funcionando do código. Mas sabemos que quase ninguém faz, até por não saber fazer, programar é ruim de UX e os especialistas nisso são raros, tem uns charlatões que dizem que são, mas basta usar aplicativos que você vê que é bem ruim.

https://www.tabnews.com.br/maniero/faq-do-programador-perdidao.

S2

---

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente (não vendo nada, é retribuição na minha aposentadoria) (links aqui no perfil também).

Meus 2 cents:

Em projetos que voce trabalhe sozinho, uma ou 2 telas, nao vai dar manutencao e bem estaticos - realmente parece nao fazer muito sentido.

Agora: trabalho em equipe, dezenas de telas, garantir a manutencao hoje e daqui 1 ano quando voce nao lembrar de mais nada sobre o sistema - bem, neste caso os testes ajudam a ter certeza que uma alteracao X nao implicou em quebra de algo eh absurdamente util.

Nao existe nada pior que fazer uma "alteracaozinha" que o usuario pediu e descobrir depois que foi para producao que isso detonou alguma parte da LP, login, etc...

O teste eh teu amigo, eh aquele cara chato que avisa "ei, mudou isto, da uma checada".

As vezes o teste nao eh apenas se a tela esta OK, mas se a funcionalidade (p.ex. api) esta normal, se o banco esta retornando os dados esperados e por ai vai.

Eh um saco ? As vezes eh mesmo - mas os testes sao uma automacao justamente para liberar voce do trabalho de ficar checando pessoalmente todo o sistema (o que eh muito mais chato no final das contas).

eu posso simplesmente acessar a tela e ver se está de acordo.

sim, da mesma forma que você pode chamar sua API com todos os casos de uso e verificar se está retornando o valor certo.

A questão é: Você vai fazer isso toda vez que mudar qualquer coisa no front? Sua demanda é mudar a cor de um botão, não faz sentido ter que repassar todas as telas vendo se as mensages de erro estão aparecendo certinho, se nenhum componente quebrou.

Imagina o trabalhão que isso geraria em um grande e-commerce?

Fazer testes para os componentes visuais é garantir que nenhuma alteração na sua base de código vá quebrar um componente que ninguém está olhando.

Para garantir que futuramente, daqui há 6 meses quando você ou seu colega desenvolver algo, esse algo novo não tenha afetado o botão. Se afetar, ao rodar a bateria de testes irá acusar.

Teste quebrou, logo:

• não sei o que você fez de novo, mas X botão parou de aparecer/funcionar, veja lá o que afetou para resolver e não aparecer bug onde já tá feito.

Chama-se Testes de Regressão: São testes criados para garantir que funcionalidades existentes continuam funcionando como antes, após uma alteração no código (como um bugfix, refatoração ou nova funcionalidade).

Há 2 opções, tem testes cobrindo as partes importantes do sistema para quando algo der ruim ele acusar, ou quando você implementar algo terá que voltar em todas telas do sistema testando tudo de novo. (a depender do tamanho do projeto, você escolhe uma delas).

Em sistemas pequenos, 2, 3 telas, realmente não precisa se preocupar tanto com isso, rapidamente você consegue ver o que quebrou, mas se o projeto crescer, 10, 15 telas, N controllers, models, services, 2, 3 pessoas mexem no projeto, ai é indispensável pensar nisso.

E oq garante a funcionalidade dele? não acho que tu esteja errado, mas o fato de exibir o botão/componente na tela não garante a funcionalidade dele ou que não esta quebrando a tela, se não tem erro no console quando clicka no botão e etc.

Por mais chato que seja, testes mesmo que feitos manualmente garantem a boa funcionalidade da aplicação