Ponta a ponta com Playwright
Alguns cenários na aplicação real valem mais do que duzentos testes em uma imitação
Testes de ponta a ponta com Playwright
Todos os seus testes unitários passam, todos os seus testes de componentes passam, e mesmo assim o funil de compra está quebrado desde esta manhã. A causa: uma variável de ambiente ausente no build de produção, que faz o cliente de pagamento apontar para uma URL vazia. Nenhum teste da suíte poderia ter detectado isso, porque nenhum deles era executado na aplicação realmente construída, servida pelo servidor de verdade, em um navegador de verdade. Cada camada funcionava; era a junção entre elas que não funcionava.
Esse é o único papel dos testes de ponta a ponta, e é ele que justifica o custo. Eles são lentos, mais frágeis e trabalhosos de diagnosticar, então você não vai escrever duzentos. Você vai escrever de cinco a quinze, sobre os fluxos cuja falha faria você perder dinheiro ou dados: cadastrar-se, entrar, pagar, publicar, excluir. Todo o resto pertence às camadas inferiores. Essa disciplina de seleção é o que separa uma suíte de ponta a ponta útil, executada a cada merge, de uma suíte de quarenta minutos que a equipe acaba contornando.
Comentários
Os comentários são alimentados pelo GitHub Discussions
Conecte-se com o GitHub para participar da discussão