Nos últimos 10 meses, os desenvolvedores da edX trabalharam duro para aumentar a cobertura de testes automatizados. Nossos 2,491 testes de unidade Python atualmente cobrem 87% das linhas no repositório edx-platform. Esses testes, juntamente com nossos testes de aceitação do Selenium e testes de unidade JavaScript, são executados em todas as solicitações de pull, permitindo validar rapidamente as alterações de código propostas.

Como aumentamos a cobertura de testes de menos de 50% para 87% em apenas 10 meses? Parte da resposta é uma ferramenta chamada capa diferencial.

Em um fluxo de trabalho típico, um desenvolvedor trabalhando em um projeto grande pode fazer uma solicitação pull que altera algumas dezenas de linhas de código. Antes da mudança, a cobertura do teste pode ter sido de 72%; depois, ainda pode ser 72%. O tamanho do projeto torna difícil ver o efeito de um único pull request. O Diff-cover permite que você se concentre nas métricas de qualidade de uma única solicitação pull em vez do projeto como um todo.

Diff-cover mede linhas de código em um git diff. Para uma alteração proposta no código, ele mostrará quais das linhas alteradas estão sem cobertura. Esta é uma ideia simples, mas tem implicações poderosas:

  • Para os desenvolvedores, o diff-cover fornece uma métrica clara e alcançável: se você tocar em uma linha de código, ela deve ser coberta.
  • Para revisores de código, o diff-cover facilita a verificação de que os desenvolvedores estão escrevendo testes para todas as alterações de código.

Ao se concentrar na cobertura de diferenças, os desenvolvedores podem dar passos pequenos e visíveis para melhorar a cobertura global. Um commit específico pode aumentar global cobertura por apenas uma fração de um por cento, mas ainda tem 95% diff cobertura. Lenta mas seguramente, à medida que os desenvolvedores escreviam testes para suas alterações de código, a cobertura global também começou a aumentar. Como resultado, conseguimos detectar certos tipos de bugs mais cedo.

Mais importante, outros desenvolvedores começaram a contribuir para o diff-cover e se apropriando da ferramenta. Por exemplo, Cale generalizou a ferramenta para dar suporte a verificações adicionais de “qualidade”, e Sarina a estendeu para relatar violações de pep8 e Pylint em um diff. Muitos outros desenvolvedores forneceram feedback e sugestões durante um teste beta inicial do diff-cover. A ferramenta tornou-se um ponto de partida para um reexame de nossos padrões de teste e revisão de código, o que levou a uma mudança real em nossa cultura de teste.

É claro que a medição de cobertura ainda tem algumas limitações importantes. Em particular, a cobertura de alta diferença não não garantir código livre de bugs: em um sistema fortemente acoplado, uma alteração em um componente pode ter consequências de longo alcance e não intencionais em outras partes do sistema - mesmo que o código alterado esteja 100% coberto. Nesses casos, os testes de integração podem detectar bugs que os testes de unidade podem perder.

Se você acha que o diff-cover pode ser útil para você, confira o projeto - é de código aberto e disponível no GitHub. O código foi projetado para ser extensível a outros sistemas de controle de versão e verificadores de qualidade, portanto, sinta-se à vontade para adicionar recursos e fazer uma solicitação pull!

Will Daly é engenheiro de testes na edX. Quando não está defendendo o desenvolvimento orientado a testes ou otimizando um cluster Jenkins, ele gosta de correr ao longo dos rios e minimizar o número de coisas em seu apartamento.

 1,382 visualizações totais