💻 computer science

Exploring Sustainability in Scientific Software through Code Quality & Test Coverage Metrics

Este estudo analisa métricas de qualidade de código e cobertura de testes em software científico de código aberto para demonstrar que projetos sustentáveis apresentam cobertura de testes mais alta e consistente e correlações código-teste mais fortes, ao mesmo tempo que destacam que a baixa testabilidade geral é frequentemente impulsionada por alta complexidade e acoplamento.

Autores originais: Sheikh Md. Mushfiqur Rahman, Gregory R. Watson, Nasir U. Eisty

Publicado 2026-05-06

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Sheikh Md. Mushfiqur Rahman, Gregory R. Watson, Nasir U. Eisty

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine o software científico como uma enorme cozinha personalizada, construída por cientistas para cozinhar novas descobertas. Algumas dessas cozinhas são bem organizadas, com rótulos claros em cada frasco de especiarias, um livro de receitas que é atualizado e uma equipe que sabe exatamente como usar o fogão. Outras são caóticas: receitas rabiscadas em guardanapos, o fogão é um mistério e, se o chef original se vai, ninguém sabe como ligá-lo.

Este artigo é como um inspetor de saúde que visitou 14 dessas cozinhas científicas para descobrir o que torna uma cozinha "sustentável" (capaz de continuar cozinhando por anos) versus uma que provavelmente desmoronará. Eles não olharam apenas para quantas pessoas estavam na cozinha; olharam para os projetos (o código) e para as verificações de segurança (os testes).

Eis o que descobriram, explicado de forma simples:

1. As Duas Maneiras de Julgar uma Cozinha

Os pesquisadores tiveram que decidir quais cozinhas eram "saudáveis" e quais eram "doentes". Usaram dois métodos diferentes, como duas maneiras diferentes de julgar um restaurante:

Método A (O Teste do "Chef Ocupado"): Eles observaram com que frequência os chefs estavam realmente cozinhando. Se uma cozinha tivesse estado ativa por pelo menos dois anos com um fluxo constante de novos pratos (commits), eles a classificaram como Sustentável.
Método B (O Teste do "Fator Caminhão"): Eles perguntaram: "Se o chef principal fosse atingido por um caminhão (ou simplesmente demitisse), a cozinha entraria em colapso?" Se houvesse chefs de reserva suficientes que conhecessem os segredos, eles a classificaram como Sustentável.

2. A Grande Surpresa: Os Testes Não Contam Toda a História

Os pesquisadores esperavam que cozinhas "Sustentáveis" tivessem sempre verificações de segurança melhores (cobertura de testes).

Ao usar o método do "Chef Ocupado": Eles estavam certos! As cozinhas ativas tinham verificações de segurança muito melhores.
Ao usar o método do "Fator Caminhão": Eles estavam errados. Algumas cozinhas classificadas como "Insustentáveis" (porque dependiam de apenas um ou dois chefs) tinham, na verdade, verificações de segurança melhores do que as "Sustentáveis".

A Lição: Apenas porque uma cozinha tem uma lista de verificação de segurança não significa que durará para sempre. Se a equipe for muito pequena ou frágil, a cozinha ainda pode falhar, mesmo que os testes sejam perfeitos.

3. O Problema do "Projeto Bagunçado"

O estudo analisou a complexidade dos projetos (o código).

A Descoberta: Nas cozinhas que eram verdadeiramente sustentáveis, havia uma conexão clara entre como a cozinha foi construída e o quão bem ela foi testada. Se a cozinha fosse bagunçada (alta complexidade) e as paredes estivessem se apoiando demais umas nas outras (alto acoplamento), as verificações de segurança eram mais difíceis de realizar.
A Analogia: Imagine tentar testar uma casa onde a tubulação está emaranhada com a fiação elétrica. É um pesadelo verificar se as luzes funcionam sem queimar um fusível. O estudo descobriu que código bagunçado e emaranhado torna difícil escrever bons testes.
O Resultado: Cozinhas sustentáveis tendiam a ter projetos mais limpos, rótulos melhores (documentação) e uma conexão mais clara entre como foram construídas e como foram testadas. Cozinhas insustentáveis eram frequentemente bagunçadas, e suas verificações de segurança não pareciam seguir nenhum padrão lógico.

4. A Regra do "Chef Mais Rigoroso"

Os pesquisadores se perguntaram: E se exigirmos que os chefs estejam ainda mais ocupados para chamar uma cozinha de "Sustentável"?

Eles elevaram a barra, exigindo ainda mais atividade para se qualificar.
O Resultado: À medida que tornavam as regras mais rigorosas, o padrão ficou cristalino. As cozinhas verdadeiramente ativas e bem mantidas tinham altas verificações de segurança. As que apenas "fingiam" estar ativas (ou estavam morrendo) tinham quase nenhuma verificação de segurança.
A Conclusão: Se você quer saber se uma cozinha científica é verdadeiramente saudável, não olhe apenas para a lista de verificação de segurança. Olhe para o quão ocupada e consistente é a equipe. Um alto nível de atividade é um sinal melhor de saúde do que os próprios testes.

5. O Estado Geral das Cozinhas Científicas

Quando olharam para todas as cozinhas juntas, a notícia não foi boa:

Baixas Verificações de Segurança: Em média, essas cozinhas científicas eram mal testadas. Muitas tinham quase nenhuma verificação de segurança em seus fogões ou fornos.
A Complexidade é a Inimiga: Quanto mais emaranhado e complexo fosse o design da cozinha, menos verificações de segurança ela tinha. Parece que, quando os cientistas constroem essas ferramentas, eles focam em fazer o "cozimento" acontecer (a ciência) em vez de construir uma cozinha segura e testável.

Resumo

Este artigo nos diz que software científico sustentável não se trata apenas de ter testes. Trata-se de ter uma estrutura bem organizada, boa documentação e uma equipe consistente que mantém o projeto vivo.

Bons sinais: Projetos limpos, rótulos claros e uma equipe que continua aparecendo para trabalhar.
Maus sinais: Fiação emaranhada, instruções faltando e depender de apenas uma ou duas pessoas para manter as luzes acesas.

Os autores concluem que, para manter o software científico vivo a longo prazo, precisamos parar de tratar o código como um esboço bagunçado e começar a tratá-lo como um edifício bem projetado, com foco na estrutura e consistência, não apenas no resultado final.

Resumo Técnico: Explorando a Sustentabilidade em Software Científico por Meio de Métricas de Qualidade de Código e Cobertura de Testes

Declaração do Problema

O software científico de código aberto (SciOSS) é fundamental para a pesquisa e a engenharia, mas frequentemente sofre de problemas de sustentabilidade a longo prazo. Diferentemente do software industrial, o SciOSS é frequentemente desenvolvido com adesão limitada aos padrões de engenharia de software, resultando em código mal estruturado, difícil de manter, sem documentação e com testes automatizados insuficientes. Essas deficiências impedem o progresso da pesquisa, reduzem a eficiência e dificultam a reprodutibilidade. Embora pesquisas existentes tenham explorado a sustentabilidade por meio de métricas sociais (por exemplo, contagem de colaboradores, atividade de commits) ou indicadores de nível de projeto, há uma lacuna significativa na compreensão de como propriedades estruturais internas do código — como complexidade, modularidade e cobertura de testes — correlacionam-se com a viabilidade a longo prazo do software científico.

Metodologia

O estudo emprega uma abordagem baseada em dados para investigar a relação entre qualidade de código e sustentabilidade dentro da Carteira de Software do CASS (Consórcio para o Avanço do Software Científico).

Conjunto de Dados e Seleção:
Os autores compilaram um conjunto de dados de 14 projetos de software científico em C/C++. Critérios rigorosos de viabilidade foram aplicados para garantir a reprodutibilidade: os projetos precisavam estar hospedados publicamente, ser compiláveis com GCC/Clang usando flags de instrumentação de cobertura (-coverage -O0 -g), ser compatíveis com extração de AST do Clang e conter suites de testes executáveis. Projetos que exigiam hardware especializado (por exemplo, drivers de GPU específicos) ou que falhavam na compilação sob instrumentação de cobertura foram excluídos.

Rotulagem de Sustentabilidade:
Os projetos foram classificados como "sustentáveis" ou "insustentáveis" usando dois métodos complementares e estabelecidos:

Critério Baseado em Tempo (t-anos): Um projeto é sustentável se tiver commits abrangendo mais de $t$ anos (definido como 2) com uma contagem mediana de commits mensais $\ge k$ (definido como 6).
Critério Fator Caminhão (TF): Um projeto é sustentável se pelo menos um desenvolvedor central do "Fator Caminhão" (um conjunto mínimo de desenvolvedores críticos para a manutenção do projeto) permanecer ativo ou for substituído com sucesso.

Coleta de Métricas:
Um conjunto abrangente de métricas estáticas e dinâmicas foi extraído usando ferramentas como Analizo, Lizard, Cloc, scripts personalizados de AST do Clang e gcovr:

Métricas Estruturais: Tamanho (LOC, NOM), Complexidade (WMC, AMC, RFC), Coesão (LCOM4), Acoplamento (CBO, ACC) e Documentação (Densidade de Comentários, Linhas de Comentários).
Métricas de Chamada de Função: Chamadas de métodos Internas vs. Externas (NMC, NMCI, NMCE).
Métricas de Qualidade de Testes: Porcentagens de cobertura de Linha, Ramo e Função.

Análise:
O estudo utilizou métodos estatísticos não paramétricos devido à distribuição não normal dos dados. A correlação de postos de Spearman ( $\rho$ ) foi usada para avaliar as relações entre métricas estruturais e cobertura de testes. Testes U de Mann–Whitney e tamanhos de efeito Delta de Cliff foram empregados para comparar distribuições entre grupos sustentáveis e insustentáveis. Análises de sensibilidade foram conduzidas variando o limiar de frequência de commits ( $k$ ) para testar a robustez das classificações de sustentabilidade.

Principais Contribuições e Resultados

1. Achados Divergentes Baseados no Método de Classificação (RQ1)
O estudo constatou que a definição de sustentabilidade impacta significativamente a relação observada entre qualidade de código e testes:

Sob o critério t-anos: Projetos sustentáveis exibiram cobertura de testes significativamente maior (linha, ramo e função) em comparação com os insustentáveis. Isso sugere que a manutenção a longo prazo correlaciona-se com investimento consistente em infraestrutura de testes.
Sob o critério TF: A tendência inverteu-se; projetos rotulados como "insustentáveis" (devido à perda de desenvolvedores-chave) mostraram cobertura de testes mediana maior do que os sustentáveis. Os autores interpretam isso como um cenário onde um pequeno grupo concentrado de desenvolvedores inicialmente construiu e testou o software minuciosamente, mas o projeto carecia do suporte comunitário mais amplo necessário para a evolução a longo prazo.
Padrões de Correlação: Projetos sustentáveis demonstraram correlações mais fortes e consistentes entre métricas estruturais e cobertura de testes. Por exemplo, maior complexidade (NMC, NMCE) e menor coesão foram negativamente correlacionados com a cobertura em projetos sustentáveis, indicando um trade-off claro. Projetos insustentáveis mostraram correlações fracas ou erráticas, sugerindo uma falta de práticas de engenharia disciplinadas.

2. Impacto de Limiares Mais Rigorosos (RQ2)
O estudo investigou se o refinamento da definição de sustentabilidade melhora a confiabilidade dos indicadores de qualidade. Ao aumentar o limiar de frequência de commits ( $k$ ) de valores baixos (2–4) para valores altos (8–32):

Em limiares mais baixos, a distinção entre projetos sustentáveis e insustentáveis quanto à cobertura de testes foi inconsistente.
À medida que o limiar se tornou mais rigoroso, o padrão estabilizou-se: projetos verdadeiramente ativos (alto $k$ ) mostraram consistentemente cobertura de testes mediana mais alta, enquanto projetos menos ativos caíram para cobertura próxima de zero.
Isso confirma que definições baseadas em atividade mais rigorosas reduzem o ruído de rótulos e capturam melhor a disciplina de engenharia associada à sustentabilidade a longo prazo.

3. Relação Geral entre Métricas de Código e Cobertura de Testes (RQ3)
Em todo o conjunto de dados, a cobertura de testes foi geralmente baixa (cobertura mediana de linha ~21%, ramo ~14%).

Complexidade e Acoplamento: Há uma correlação negativa moderada entre complexidade/acoplamento estrutural (por exemplo, NMCE, NMC, WMC) e cobertura de testes. Maior dependência externa e complexidade parecem dificultar a testabilidade.
Documentação: Métricas como Densidade de Comentários (CD) mostraram correlações positivas ligeiras com a cobertura, sugerindo que melhor documentação pode facilitar os testes, embora a relação seja fraca.

Significado e Alegações

O artigo alega oferecer uma estrutura prática e baseada em dados para avaliar a sustentabilidade do software científico, vinculando a qualidade interna do código à viabilidade a longo prazo. Seu significado principal reside em deslocar o foco de indicadores puramente sociais ou baseados em atividade para propriedades estruturais de engenharia.

Os autores concluem que:

Cobertura de testes sozinha é insuficiente: Alta cobertura não garante sustentabilidade se a base de desenvolvedores for frágil (como visto nos resultados da classificação TF).
Integridade estrutural importa: Projetos sustentáveis são caracterizados por uma relação coerente entre estrutura de código e testes. Eles tendem a ter melhor documentação, designs mais modulares e práticas de engenharia consistentes.
Definições refinadas são necessárias: O uso de limiares mais rigorosos para "atividade sustentada" produz distinções mais confiáveis na qualidade do software, ajudando a identificar projetos que são genuinamente saudáveis versus aqueles que são meramente ativos no curto prazo.
Insights Acionáveis: As descobertas sugerem que desenvolvedores e partes interessadas devem monitorar métricas estruturais (complexidade, acoplamento) e documentação como sinais de alerta precoce de declínio na sustentabilidade, em vez de depender apenas de contagens de commits ou porcentagens de cobertura.

O estudo reconhece limitações, incluindo o pequeno tamanho da amostra (14 projetos) e a exclusão de projetos complexos dependentes de hardware, o que pode introduzir viés de sobrevivência. No entanto, a instrumentação rigorosa e o pipeline de análise padronizado fornecem uma base reprodutível para pesquisas futuras sobre as características de engenharia de software científico sustentável.