What Do Contribution Guidelines Say About Software Testing?

Imagine projetos de software de código aberto como cozinhas comunitárias imensas e movimentadas. Qualquer pessoa pode entrar, pegar uma faca e começar a picar vegetais (escrever código) para ajudar a cozinhar uma refeição melhor. Mas, para manter a cozinha funcionando sem problemas, os chefes de cozinha (mantenedores do projeto) deixam um Livro de Regras sobre o balcão. Este Livro de Regras diz aos novos ajudantes como lavar as mãos, onde encontrar os ingredientes e como entregar seus vegetais picados sem estragar a sopa.

Este artigo é como uma equipe de pesquisadores que entrou em 200 dessas famosas cozinhas comunitárias (especificamente aquelas que utilizam as linguagens Python e JavaScript) para ler os Livros de Regras e ver o que eles realmente dizem sobre testes.

No mundo da culinária, "testar" é como provar o prato antes de servir para garantir que ele não tenha gosto de sabão. Os pesquisadores queriam saber: Os Livros de Regras realmente ensinam os novos ajudantes a provar a comida ou apenas assumem que todos já sabem como fazer isso?

Aqui está o que eles descobriram, dividido de forma simples:

1. A maioria das cozinhas tem uma seção de "Provar" (mas não todas)

Os pesquisadores descobriram que 78% das cozinhas tinham uma seção específica em seu Livro de Regras dedicada a provar (testar).

• Onde está? Na maioria das vezes (58%), está em um arquivo literalmente chamado "CONTRIBUTING" (o manual de instruções principal). Às vezes, está em um folheto separado e mais sofisticado (documentação externa) e, raramente, está apenas rabiscado no cardápio principal (README).
• A Lacuna: Cerca de 22% das cozinhas não tinham nenhuma instrução sobre como provar. Se você entrasse nessas cozinhas, teria que adivinhar como verificar se a sua comida estava boa.

2. O desequilíbrio do "Como Fazer": Executar vs. Escrever

Quando os Livros de Regras falavam sobre provar, eles eram muito bons em uma coisa, mas ruins em outra.

• O "Como Executar" (83,5%): A maioria dos Livros de Regras dizia claramente: "Aqui está o feitiço mágico (comando) para provar toda a panela". É como dizer: "Pressione este botão para verificar o sabor".
• O "Como Escrever" (37%): Muito menos Livros de Regras explicavam como realmente criar um novo teste de sabor. É como dizer: "Pressione o botão", mas não ensinar você a fazer uma nova colher ou a saber o que é um sabor "ruim".
• O Resultado: Os ajudantes sabem como verificar a comida existente, mas muitas vezes ficam adivinhando como criar seus próprios testes para os novos ingredientes que adicionaram.

3. O Problema da "Pirâmide de Testes"

No software, existem diferentes níveis de teste, como diferentes tipos de testes de sabor:

• Testes de Unidade (71%): Estes são como provar um único ingrediente (ex: "Esta cenoura está doce?"). Os Livros de Regras falavam muito sobre isso.
• Testes de Integração (20,5%): Estes são como provar como a cenoura e a cebola trabalham juntas na panela. Os Livros de Regras raramente mencionavam isso.
• Testes de Ponta a Ponta (15,5%): Este é como provar a refeição completa e totalmente cozida para ver se o prato inteiro funciona. Os Livros de Regras quase nunca falavam sobre isso.

A Metáfora: Os chefs estão muito preocupados em garantir que as cenouras estejam certas, mas raramente dizem aos ajudantes como verificar se o ensopado inteiro vai queimar ou se os sabores se misturam bem.

4. As "Armas Secretas" Ausentes

Os pesquisadores também procuraram por dicas de culinária avançadas que ajudam a tornar os testes mais fáceis e confiáveis:

• Mocking (9,5%): Às vezes, você não pode provar a água do mar real na sua sopa; você precisa usar um saleiro falso para simular. Isso é chamado de "mocking". Apenas 1 em cada 10 cozinhas tinha instruções sobre como usar essas ferramentas falsas.
• Cobertura/Coverage (25,5%): Esta é uma pontuação que mostra quanto da receita foi realmente provada. Apenas cerca de um quarto das cozinhas disse aos ajudantes qual pontuação eles deveriam buscar.
• Boas Práticas (9%): Dicas gerais como "Sempre prove antes de servir" eram muito raras.

A Conclusão

O artigo conclui que, embora a maioria dos projetos de código aberto queira que seus ajudantes testem seu trabalho, as instruções que deixam para trás são desequilibradas.

Eles são ótimos em dizer: "Aqui está como você executa o teste", mas costumam ser silenciosos sobre:

• Como escrever um novo teste.
• Como testar interações complexas (integração).
• Como testar todo o sistema (ponta a ponta).
• Como usar ferramentas avançadas (mocking) ou definir metas de qualidade (cobertura).

A Lição: Se você é um novo ajudante em uma dessas cozinhas, você pode saber como apertar o botão de "provar", mas pode ser deixado sozinho para descobrir como realmente criar um teste de sabor para sua nova receita, ou como garantir que seu novo prato não vá estragar toda a refeição. Os autores sugerem que os líderes de projeto precisam escrever instruções mais claras e completas para que os ajudantes não precisem adivinhar.