Coisas a considerar ao testar a unidade de um front-end

Olá, Habr!



Gostaríamos de chamar sua atenção para mais uma novidade disponível em nossa pré-encomenda - um livro sobre testes de unidade .







O autor da publicação de hoje fala breve e claramente sobre as vantagens dos testes de unidade e TDD usando o front-end como um exemplo.



Gostar de ler!



O teste de unidade é uma das abordagens mais importantes que todo desenvolvedor deve adotar. No entanto, já vi muitos projetos em que pode ser difícil colocar o teste de unidade em prática. Existem várias razões para isso. Por exemplo, alguém pode dizer que você precisa se concentrar no desenvolvimento de recursos e, nesse caso, escrever testes de unidade é um fardo adicional sério. Outros notarão que testar seu código não é trivial porque o código em si é complexo. Em ambos os casos, o ponto é perdido.

Lembro-me desta expressão: ao pensar se você tem tempo para escrever testes de unidade, pense se você terá tempo extra para processar o mesmo código duas vezes, devido a bugs e problemas que irão surgir nele.

Escrevendo código testável



Primeiro, vamos definir quais erros comuns tornam o teste de seu código mais difícil. Quando se trata de teste de front-end, um dos problemas mais difíceis que conheço é testar os componentes da interface do usuário. O principal problema que encontrei neste caso é este: acontece que os componentes são muito "inteligentes" e estão pendurados com dependências em outros fragmentos de código, por exemplo, de chamadas de API, carregamento de dados, manipulação de eventos e implementação de lógica de negócios. Muitos desenvolvedores não gostam de escrever testes para esses componentes "pesados".



A solução mais simples para esse problema é separar os componentes em lógica e apresentação. Com essa separação, você pode testar como os componentes de apresentação aderem à lógica de apresentação, executar processamento e renderização de eventos e se concentrar separadamente em testar a lógica de negócios nos componentes responsáveis ​​pela lógica.

Garantir que seus componentes possam ser testados também é uma boa maneira de garantir que eles sejam independentes, reutilizáveis ​​e convenientes para serem usados ​​juntos. Isso é absolutamente essencial, especialmente ao compartilhar componentes entre projetos usando ferramentas e plataformas populares como o Bit ( Github) Normalmente, o Bit exibe e testa cada um dos seus componentes separadamente e só então os envia para uma coleção compartilhada, garantindo assim que eles sejam realmente reutilizáveis ​​- caso contrário, qual é o ponto de torná-los separáveis?







Exemplo: Explorando Componentes React Reutilizáveis ​​Compartilhados em Bit.dev



Um círculo vicioso: o que acontece se você não escrever testes de unidade



Pela minha experiência com equipes que não aplicam o teste de unidade corretamente (ou seja, não usam a cobertura de teste como métrica), o teste de unidade foi iniciado tarde demais ou desde o início, mas não aprendeu como praticá-lo. Pode haver muitas razões para isso, mas darei alguns exemplos para tornar mais fácil para você decidir qual deles é mais semelhante ao seu caso.



Como testamos nosso código durante o desenvolvimento



Na minha opinião, a menos que você se limite ao desenvolvimento orientado a testes (TDD), a funcionalidade pode ser desenvolvida desde que o front-end seja constantemente carregado no navegador. Você precisa se concentrar em visualizar a funcionalidade e as interações que ocorrem na interface do usuário, pois essa é a essência do desenvolvimento do lado do cliente.



Só depois disso, quando todas as funcionalidades já estão funcionando, o foco muda para o teste de unidade.



Aqui está o principal problema que você deve enfrentar: escrever testes de unidade é um trabalho adicional executado após a conclusão do desenvolvimento da funcionalidade. Essa abordagem leva à impressão de que o teste de unidade é uma tarefa adicional executada em cima do desenvolvimento de funcionalidade pronta.



Por causa dessa formulação da pergunta, tanto os proprietários do produto quanto os desenvolvedores classificam o teste de unidade como um custo.



Mas, se você se limitar ao TDD, tudo se desenvolverá exatamente ao contrário. Como os casos de teste são escritos com antecedência, não precisamos verificar tudo visualizando constantemente as mudanças, porque temos uma maneira diferente de verificar o código durante o desenvolvimento. Nesse caso, a principal ferramenta de verificação é escrever código que passará no caso de teste de unidade.



Portanto, acredito que a prática do TDD é a etapa mais importante antes da prática dos testes unitários.



Com que frequência os testes de unidade são executados



Você pode estar se perguntando como a execução de um teste de unidade afeta como os testes de unidade são escritos. Por exemplo, digamos que você tenha um conjunto completo de testes. Você o bane de vez em quando. Portanto, os desenvolvedores raramente se convencem de sua utilidade. Além disso, mesmo quando o teste falha, é tarde demais.

Portanto, é importante executar testes de unidade pelo menos em todos os estágios da construção da solicitação pull. Ao aderir a essa prática, obtida do DevOps, garantimos que cada novo bloco de código que adicionamos passe em um conjunto de testes de unidade. Mesmo que haja necessidade de alterar um caso específico, o desenvolvedor o fará antes do ato de mesclagem de código.



Com que frequência medir a cobertura de código por meio de testes



Tal como acontece com a execução de teste, essa medição também é importante psicologicamente e como prática para os desenvolvedores julgarem se preparam casos de teste suficientes para cobrir todo o código escrito.

Neste caso, creio que não basta apenas um painel, no qual se possa visualizar a cobertura dos testes unitários. Mas, se fosse possível adicionar um ato de medição ao adicionar um novo código e, assim, verificar o nível de cobertura do teste, essa alternativa seria mais conveniente para obter feedback instantâneo. Poderíamos até mesmo formular regras exigindo que qualquer novo código adicionado ao banco de dados fosse coberto por testes, digamos, 80%. É mais apropriado adicionar essa validação ao processo de construção da solicitação pull.



Como os desenvolvedores recebem feedback instantâneo sobre a cobertura do teste de unidade de seu código, eles são livres para tomar as medidas necessárias para atualizar a cobertura conforme necessário.



Saindo deste círculo



Se você já está envolvido nesse círculo vicioso, a melhor maneira de sair dele é reforçar as práticas discutidas acima. Visto que o acima foi sobre testes frequentes para validar o código recém-adicionado, bem como a cobertura de teste do novo código, você pode desenvolver um procedimento que seja adequado para qualquer operação de adição ou alteração de código.

É extremamente improvável que você tenha tempo suficiente para cobrir todo o código antigo com testes (a menos que o projeto em si seja completamente novo) imediatamente, antes de ter que escrever um novo código. Portanto, não conte com isso de forma alguma, porque do ponto de vista do negócio, é impraticável.
Nesse ínterim, você pode fazer medições periódicas, cobrindo estrategicamente certas partes do código antigo com testes. Mais importante ainda, você deve treinar todos os desenvolvedores para seguir esta prática. É igualmente importante desacostumar-se a considerar este trabalho como um custo e transmitir a todos os donos de projetos como é importante escrever testes de unidade. Caso contrário, pode parecer a muitos, especialmente aos não técnicos, que o teste de unidade é um trabalho desnecessário, em vez do qual alguém poderia gastar tempo desenvolvendo novas funcionalidades.



Então, qual é o verdadeiro valor de todo esse trabalho



Os testes de unidade são úteis de várias maneiras. Se aplicados corretamente, eles ajudam a reduzir o número de defeitos no código, agem como seguro ao testar a funcionalidade existente, não são danificados ao refatorar o código e também ajudam a manter a produtividade geral em um nível alto.

Olhando para o código bem coberto pelos testes de unidade, todos podem ver o quão confiante ele parece.
Portanto, vamos preencher as lacunas e voltar aos trilhos adotando práticas de DevOps e nos acostumando a escrever bons testes de unidade, ao mesmo tempo que nos mantemos no desenvolvimento orientado a testes.



All Articles