Sobre 100% de cobertura de código

A mentalidade de teste para desenvolvedores mudou ao longo dos anos, à medida que o software a indústria está evoluindo. Mesmo assim, a prática de teste não é amplamente utilizada, ela é integrada na ciclo de desenvolvimento da aplicação. Como tal, a cobertura de código se tornou um assunto popular entre os desenvolvedores e as discussões aumentaram a fim de chegar a um consenso de Cobertura de código.

Esta postagem tem como objetivo dar um impulso a essa discussão e compartilhar o que penso sobre a cobertura de código o que vejo as equipes fazendo e o que entendo que é eficaz ou não.

Desenvolvimento guiado por testes

O desenvolvimento dirigido por teste foi (TDD) adotado para desenvolvedores a fim de alcançar software de alta qualidade, bem como para mantê-lo evoluindo ao longo do tempo e evitar o medo da mudança. Portanto, [1] e [2] descreve como TDD sendo um fluxo de três estágios (vermelho-verde-azul), não é o que eu identificar nos projetos em que trabalhei.

A maioria desses projetos estava usando uma combinação de ITL (último teste interativo) ou não fazia nenhum teste, o teste foi aplicado a um profissional de controle de qualidade (garantia de qualidade). Neste cenário, a equipe não era obter qualquer valor no momento para manter os testes atualizados ou mesmo para escreva-os. Essa é uma discussão inteira que não vou abordar aqui, no entanto, é o que possivelmente leva a perder as principais métricas. Como sempre, gerenciamento tente forçar os desenvolvedores a alcançar 100% de cobertura apenas por causa disso, ou porque eles viram que poderiam usar isso para forçar algum tipo de comportamento nos desenvolvedores. O catálogo de James Carr chamou esse antipadrão de “The Liar”, que Dave Farley usa como base para discutir o assunto em seu vídeo [3] ([4]) também mencionam que a meta de cobertura é uma compreensão equivocada em seu vídeo sobre Desenvolvimento Orientado a Comportamento).

TDD é uma rede segura para os desenvolvedores continuarem melhorando o código, comunicar a intenção e também uma cultura a seguir. Como Dave Farley diz em seu vídeo: pratique TDD e evite a armadilha do mentiroso.

Portões de qualidade

Portas de qualidade são usadas para fazer cumprir algumas regras mínimas durante o desenvolvimento de software ciclo da vida. Entre as diferentes regras, podemos listar:

  • Codificação
  • Suíte de teste
  • Verificações de segurança
  • Orçamento de desempenho

Muitos argumentariam que a cobertura de código teria seu lugar, o que eu concordo. Poderíamos usar a cobertura de código como uma porta para não permitir a produção de código, se a base de código tem menos de X porcentagem que falha no processo de lançamento. Portanto, além de ser uma porta de qualidade, deve ser uma indicação da integridade do conjunto de testes.

A equipe deve confiar no conjunto de testes e a cobertura deve refletir a saúde da suíte. O que, em muitos casos, não é o que acontece. A abordagem comum é ter como alvo X por cento de cobertura, não importa o quê.

Evite métricas erroneas

Minha experiência diz que, para muitos desenvolvedores, os testes são necessários, de obrigação. Eles escrevem os testes não porque querem se orgulhar do trabalho que eles fazem, ou porque querem dar ao próximo desenvolvedor (que irá manter isso no futuro) uma dica sobre o que o código foi construído para oferecer suporte ou não.

Como tais gerentes, tentem impor a ideia de que forçar os desenvolvedores a alcançar X porcentagem de cobertura aumentará a qualidade da base do código. [5] gravou um vídeo de 3 séries passando pelo famoso kata Gilded Rosa, que o objetivo é refatorar o código fornecido. Por volta do minuto 15:59 do primeiro vídeo que ela mostra um problema nos testes que ela fez. Embora ela mudou uma parte crítica do código de produção, os testes estavam passando. O o código tinha cobertura de um centavo de pecent. Não estava dando o feedback desejado.

Claro que era um kata e ela descreve esse problema lindamente enquanto prossegue através do código.

Ainda assim, vejo os desenvolvedores se orgulhando de si mesmos porque têm X porcentagem de cobertura.

Esta série de vídeos por si só aponta como a matriz de cobertura percentual X é inútil.

A cobertura do código deve ser um efeito colateral da qualidade do conjunto de testes [4], em que os desenvolvedores de software podem confiar e entender que os testes são uma rede segura para a melhoria contínua do código.

Referencias

  1. [1]K. Beck, TDD by example. Addison-Wesley Professional, 2000.
  2. [2]M. Fowler, “TestDrivenDevelopment,” 2005 [Online]. Available at: https://martinfowler.com/bliki/TestDrivenDevelopment.html. [Accessed: 31-May-2021]
  3. [3]D. Farley, “When Test Driven Development Goes Wrong,” 2021 [Online]. Available at: https://youtu.be/UWtEVKVPBQ0?t=243. [Accessed: 05-Jun-2021]
  4. [4]D. Farley, “BDD Explained (Behaviour Driven Development,” 2021 [Online]. Available at: https://www.youtube.com/watch?v=zYj70EsD7uI. [Accessed: 27-May-2020]
  5. [5]E. Bache, “Introducing the Gilded Rose kata and writing test cases using Approval Tests,” 2018 [Online]. Available at: https://www.youtube.com/playlist?list=PLuvRKxeqrv4K-rn0zxHPNiXOWBkP9ZZIH. [Accessed: 31-May-2021]