Nada de janelas quebradas

Publicado por Vinicius Manhães Teles há aproximadamente 1 ano.

Diz a lenda que, há alguns anos, fizeram o seguinte experimento em Nova York. Estacionaram um carro em um bairro perigoso e o deixaram lá durante uma semana. Após esse período, ele ainda estava lá, inteiro. Então, os pesquisadores jogaram uma pedra no vidro do carro e foram embora. Não precisaram nem esperar uma semana. No dia seguinte o carro já estava completamente depenado e destruído. Uma única janela quebrada foi suficiente para iniciar o processo de vandalismo.

David Thomas e Andrew Hunt tratam desse assunto no livro The Pragmatic Programmer. Eles mostram como a cidade de Nova York usou a Teoria das Janelas Quebradas para reduzir a violência e como nós, desenvolvedores, podemos usá-la para evitar que o design de nossas aplicações se degradem. Resumidamente, a idéia é que um código permanentemente bem escrito, tenderá a ser mantido assim, pois as pessoas ficam "sem graça" de estragá-lo. Por outro lado, um código que já tem várias gambiarras é um convite para outras novas.

Há algum tempo tive a idéia de usar a análise de cobertura dos testes como uma forma de contribuir para achar as janelas quebradas e consertá-las rapidamente. Embora a cobertura não diga se os seus testes estão bons ou não, ela ao menos indica se existem partes do código que não estão sendo exercitadas por testes. E isso é bastante útil.

Trabalhando com XP, nós integramos o código freqüentemente, portanto, uma idéia seria rodar a análise de cobertura antes de cada commit no repositório. Assumindo que o projeto tenha 100% de cobertura, o desenvolvedor que der o commit roda a análise e, se o software continuar em 100% de cobertura, o commit é feito. Senão, ele deve implementar os testes que estão faltando. Usado consistentemente, isso pode ajudar a criar uma pressão positiva na equipe, no sentido de nunca comitar código sem teste.

Existem dois problemas com essa abordagem. O primeiro é atingir 100% de cobertura. Isso tipicamente é mais viável se o projeto já utilizar TDD desde o início. É bem mais complicado para projetos que já começaram sem testes. O segundo problema é que o desenvolvedor pode simplesmente deixar de rodar a análise de cobertura antes de fazer o commit.

Resolvemos esses problemas no desenvolvimento de nosso produto de duas formas. Primeiro, o projeto tem ênfaze em automação de testes desde o início. Sendo assim, temos 100% de cobertura. Para que isso seja mantido, fiz uma melhoria no nosso script de integração.

Temos um script que é executado antes de cada commit. Ele executa todos os nossos testes, além de fazer outras checagens, e só faz o commit se tudo estiver ok. A partir de hoje ele tem um passo adicional: executa a análise de cobertura e só permite o commit se ela estiver em 100%. Agora vai ser difícil alguém deixar janelas quebradas pelo código, quer dizer, esses tipos de janelas quebradas, já que existem outras também que não são identificadas pela análise de cobertura.

Esse projeto utiliza Ruby on Rails, portanto, a ferramenta usada para a análise de cobertura é o rcov que gera telas como essa:

Essa imagem é do próprio site do rcov. A análise de cobertura do nosso produto não tem essas cores vermelhas, naturalmnete. :-)

Tags qualidade, teste | 5 comentários