Já estou entrevistando há um bom tempo. O que se destacou neste doloroso processo foi que a entrevista estaria condenada se a questão do teste fosse levantada. Isso ocorre porque minhas experiências foram principalmente em desenvolvimento de front-end e as duas empresas em que estive eram muito ruins em testes de front-end.

--- Pule se quiser ir direto para a discussão ---

Minha falta foi, em certo sentido, um subproduto da cultura da indústria. Os testes de front-end sempre existiram, mas há uma década a estrutura da empresa separava as preocupações de teste do processo de desenvolvimento. Portanto, tínhamos uma equipe de controle de qualidade dedicada que escreveria testes E2E/automatizados para nós, desenvolvedores. Portanto, o teste nem estava na descrição do trabalho. Além disso, a triste verdade das pequenas startups é que a entrega está sempre acima de tudo, então, como os testes prejudicam a produtividade, nós, desenvolvedores, não testamos. Nem tínhamos nenhuma biblioteca de testes (Jasmine/Mocha/PhantomJS...) instalada no repositório.

Consegui meu segundo emprego em uma empresa muito maior (a equipe da plataforma de consumo tinha cerca de 150 desenvolvedores?). No entanto, não houve testes muito essencialmente falando. Cada equipe (equipes divididas por recursos como checkout, fidelidade, registro...) novamente tinha membro(s) de controle de qualidade dedicado(s) que escreveriam esses testes E2E. Depois que essa cultura se estabeleceu e o controle de qualidade foi cortado do orçamento, ninguém os escolheu porque não havia ninguém com quem aprender. Tentei fazer alguns testes E2E para nossa equipe, mas o código deixado para trás nem era funcional e estava cheio de bugs óbvios (muitos WTFs). Combinado com prazos apertados NOVAMENTE, os testes ficaram para trás. A única vez que as pessoas falaram sobre testes foi para funções utilitárias e ganchos de reação personalizados.

--- discussão começa ---

Sendo atormentado pela cultura de não teste, tenho que pelo menos inventar algo que possa dizer durante as entrevistas sobre testes de forma abstrata. Vou pular as besteiras habituais de não testar estilos ou implementar o que não é.

Sinta-se à vontade para contribuir com a discussão. Isso afeta pelo menos 300 dos meus ex-colegas de trabalho!

1.) testar estados globais:
Em minhas experiências, uma das características mais complicadas é o tipo de comportamento "se isso acontecer, faremos isso automaticamente para você". Por exemplo, um aplicativo que eu tinha era um painel de visualização de gráfico altamente configurável. Uma alteração na configuração pode fazer com que outras configurações também sejam alteradas, dependendo dos dados retornados e quais não. Alguns efeitos colaterais da configuração não são simples. Portanto, você desejará testar as alterações automáticas na configuração e se o estado é persistente/inalterado/consistente em todos os aspectos. Portanto, se você tiver testes em torno desse tipo de comportamento, alinhado com PM, gerentes, design e equipe de controle de qualidade é imensamente valioso.

2.) não gaste muito tempo testando a integridade da entrada da IU:
Vejo alguns tutoriais falando sobre testes de entradas, como quando digito "taylor swift" na barra de pesquisa e pressiono enter, nossa função de pesquisa obterá taylor swift como entrada.

Isso é totalmente inútil. Se a sua ligação de dados for quebrada, será muito óbvio que você mesmo deveria tê-la detectado durante o desenvolvimento ou não será testável automaticamente porque algo estava atrapalhando a funcionalidade, como um div invisível acima da barra de pesquisa para que os usuários não possam digitar na pesquisa.

se você está sendo pago por linhas de código, vá em frente :)

3.) testar entradas como efeito colateral das entradas, embora seja desejável:
ao contrário do número 2, você desejará testar chamadas funcionais que são completamente efeitos colaterais para a interação do usuário. Por exemplo, quando o usuário clica em um botão, uma solicitação deve ser chamada para registrar essa ação do usuário para análise de dados. Este tipo de efeito colateral, completamente separado da funcionalidade principal, deve ser testado automaticamente para que não sejamos pegos de surpresa por algumas alterações não intencionais. Efeito colateral não essencial pode ser essencial para outras equipes, eu estive em uma dessas outras equipes: D

Então, como você arquiteta esses requisitos de teste?
vamos analisar a arquitetura frontend: MVC (você pode dizer que é MVVM ou algo assim, isso realmente não importa).

V - view (html/jsx): Isso é ótimo para testes de navegador E2E/sem cabeçalho e é um padrão da indústria.

C - controlador (lógica de negócios): gaste algum tempo certificando-se de que as funções estão corretas. Por exemplo, se você tem/abstrai funções puras, o processo de entrada-saída esperado ainda está intacto? Um tanto padrão da indústria, mas as pessoas geralmente não se preocupam em transformar funções com estado em funções puras e testes.

M - modelo (chamadas/estados de API): é nisso que quero me concentrar mais. seus estados (sem renderização) devem ser globais e únicos por conceito. Não é uma ideia nova, já que Redux é basicamente isso. No entanto, não precisa ser Flux para fins de teste. Você pode ter átomos jotai, mas pode codificar um wrapper para poder expor suas funções setter centralizadas para teste.

algo semelhante deve ser feito em suas chamadas de API/bibliotecas de terceiros. Deve ser global e singleton para que você possa testar com segurança "quando eu faço isso, é uma chamada de API principal/não principal feita no aplicativo". Isso é feito rotineiramente, em minha experiência limitada, em aplicativos de back-end. Isso também deve ser feito em aplicativos frontend.

Como isso soa? Tenho certeza que alguém já faz isso, qual é a sua experiência? o que pode ser melhorado? Eu adoraria ouvir de pessoas onde os testes de front-end vão além do navegador E2E/headless e dos testes de unidade simples e estúpidos.