Cross-Project Flakiness: A Case Study of the OpenStack Ecosystem

Imagine que você faz parte de uma equipe de construção massiva e global, erguendo uma cidade de nuvens gigante e complexa chamada OpenStack. Esta cidade não é construída por uma única pessoa; é erguida por milhares de trabalhadores (desenvolvedores) atuando em centenas de bairros diferentes (projetos), como Cinder, Glance e Nova. Para garantir que a cidade não desmorone, sempre que alguém adiciona um novo tijolo ou altera um cano, eles executam uma série de "verificações de segurança" automatizadas (testes).

Idealmente, essas verificações de segurança deveriam ser como um semáforo perfeito: Verde significa "Pode seguir, a alteração é segura", e Vermelho significa "Pare, há um problema".

Mas, às vezes, o semáforo pisca. Ele fica Vermelho sem motivo aparente, depois Verde quando você verifica novamente, e Vermelho outra vez. No mundo do software, isso é chamado de "Instabilidade" (Flakiness). É como um teste que está apenas "de mau humor" — ele não sabe se está passando ou falhando, mesmo que nada tenha mudado no código.

Este artigo é uma história de detetive sobre como esse comportamento "de mau humor" se espalha por toda a cidade do OpenStack, e não apenas em um único bairro.

Os Dois Grandes Problemas que Eles Encontraram

Os pesquisadores descobriram duas maneiras específicas pelas quais esse comportamento "de mau humor" causa problemas:

1. O Glitch "Contagioso" (Instabilidade entre Projetos)
Imagine uma verificação de segurança específica (um teste) que deveria verificar se uma fechadura de porta funciona. Nesta cidade, essa mesma verificação de fechadura é usada no bairro Cinder, no bairro Glance e no bairro Nova.

• O Problema: A verificação de fechadura está "de mau humor". Ela falha aleatoriamente em todos os três bairros.
• O Impacto: Como os bairros compartilham esse único teste, um único teste defeituoso interrompe o progresso em múltiplos lugares ao mesmo tempo. Os pesquisadores descobriram que 55% de todos os bairros no OpenStack são afetados por esses glitches contagiosos. É como uma única maçã podre estragando todo o barril, mas a maçã é, na verdade, um teste que todos estão usando.

2. O Glitch "Seletivo" (Instabilidade Inconsistente)
Agora, imagine que essa mesma verificação de fechadura é usada no bairro Cinder e no bairro Nova.

• O Problema: Em Cinder, o teste é perfeitamente confiável (sempre Verde). Mas em Nova, o mesmo teste exato está "de mau humor" (piscando entre Vermelho e Verde).
• O Impacto: Isso é confuso! Significa que o próprio teste não está quebrado; algo sobre o ambiente em Nova está causando o problema. É como um carro que liga perfeitamente na sua garagem, mas engasga toda vez que você tenta ligá-lo na casa de um amigo. Os pesquisadores encontraram mais de 1.100 desses glitches "seletivos".

A Grande Surpresa: Até os Testes "Unitários" Estão Ficando Doentes

Geralmente, os desenvolvedores pensam nos Testes Unitários como os "microscópios" do mundo do software. Eles examinam pedaços minúsculos e isolados de código (como uma única função) no vácuo. Eles deveriam ser os testes mais estáveis e previsíveis, pois não se comunicam com o mundo exterior.

A Descoberta Chocante do Artigo:
Os pesquisadores descobriram que 70% desses testes de "microscópio" estão, na verdade, envolvidos nos glitches "Contagiosos".

• Analogia: É como descobrir que os parafusos minúsculos e isolados que seguram sua torradeira são os mesmos parafusos que estão causando um curto-circuito em todo o sistema elétrico da cozinha. Assumíamos que esses pequenos testes eram seguros e isolados, mas em um ecossistema gigante, eles estão profundamente conectados e podem espalhar instabilidade para todos os lugares.

Por Que Isso Acontece? (As Causas)

A equipe analisou os registros para descobrir por que os testes estavam agindo de forma estranha em alguns lugares e não em outros. Eles encontraram três principais culpados:

1. A "Condição de Corrida" (O Assassino de 89%): Esta é a causa mais comum. Imagine dois trabalhadores tentando pegar a mesma ferramenta no mesmo milissegundo. Às vezes o Trabalhador A consegue; às vezes o Trabalhador B consegue. Se o teste tentar pegar um recurso (como um servidor ou um arquivo) que já está sendo usado por outra coisa, ele falha. Se conseguir, ele passa. Essa aleatoriedade é chamada de "condição de corrida".
2. Configurações Incompatíveis: É como tentar assar um bolo usando uma receita de um país, mas ingredientes de outro. O teste espera uma configuração específica (como uma versão específica de uma biblioteca ou uma velocidade específica de servidor), mas o ambiente não corresponde.
3. Problemas de Dependência: Um bairro pode ter atualizado sua "rede elétrica" (uma biblioteca de software), enquanto a cidade vizinha não atualizou. O teste funciona na cidade atualizada, mas falha na antiga.

O Custo da Abordagem "Esperar e Ver"

Quando um teste falha, a reação padrão no OpenStack é dizer: "Ah, deve ser um glitch. Vamos apenas executá-lo novamente (recheck) e esperar".

• O Custo: Os pesquisadores calcularam que esse hábito de "reexecutar e esperar" desperdiçou 1.156 dias de tempo de computação e dinheiro.
• A Analogia: É como um policial de trânsito ver uma luz vermelha, assumir que o sensor está quebrado, acenar para os carros passarem, verificar novamente e acenar para eles passarem novamente. Isso desperdiça combustível (recursos de computação) e atrasa o deslocamento de todos (revisões de código).

O Que os Trabalhadores Dizem? (Feedback dos Desenvolvedores)

Os pesquisadores perguntaram aos construtores reais (desenvolvedores) sobre isso.

• A Frustração: Muitos desenvolvedores se sentem impotentes. Eles dizem: "Sou novo, não sei a quem perguntar, então continuo clicando em 'recheck' até passar".
• A Realidade: Eles admitem que corrigir esses problemas é difícil, pois exige conversar com múltiplas equipes. Se um teste falha em Nova por causa de um problema em Cinder, o desenvolvedor de Nova tem que esperar a equipe de Cinder corrigir.
• A Lacuna de Ferramentas: Eles mencionaram que, embora existam ferramentas para ajudar, elas frequentemente quebram ou são abandonadas porque ninguém tem tempo para mantê-las. Eles precisam de um "mecânico" dedicado para o sistema de Integração Contínua (CI), e não apenas voluntários fazendo isso de lado.

A Conclusão

O artigo conclui que, em um ecossistema de software gigante e conectado, você não pode tratar os testes como ilhas isoladas.

• Para Desenvolvedores: Pare apenas de "reexecutar" e esperar. Investigue por que um teste falhou, mesmo que pareça não ter relação com seu código.
• Para Líderes de Equipe: É necessário padronizar como os testes são executados em todos os bairros. Se uma cidade usa uma ferramenta específica, todos devem usar. Você também precisa centralizar o rastreamento desses glitches para que todos saibam quais "parafusos" estão frouxos.
• Para o Futuro: Precisamos de melhores ferramentas para nos dizer automaticamente por que um teste é instável (por exemplo: "Falhou porque o servidor estava fora do ar", e não apenas "Falhou").

Em resumo, o artigo argumenta que, para manter a cidade do OpenStack funcionando suavemente, precisamos parar de tratar falhas de teste como má sorte aleatória e começar a tratá-las como um problema sistêmico de coordenação que afeta toda a cidade.