A First Look at the Self-Admitted Technical Debt in Test Code: Taxonomy and Detection

O software nunca está verdadeiramente finalizado. Mesmo após o lançamento de um programa, os desenvolvedores devem retornar constantemente a ele para corrigir erros, adicionar novos recursos e adaptar-se a necessidades em constante mudança. Esse trabalho contínuo é chamado de manutenção e, muitas vezes, exige mais esforço do que a criação inicial do próprio software. Para tornar esse trabalho gerenciável, os programadores às vezes deixam notas em seu código, admitindo que uma determinada seção está bagunçada, é temporária ou não está totalmente correta. Eles podem escrever um comentário dizendo: "Isso é um improviso" ou "Corrigir isso depois". No mundo da engenharia de software, essas admissões honestas são conhecidas como dívida técnica autoadmitida. Elas são como um desenvolvedor dizendo: "Eu sei que esta não é a melhor maneira de fazer isso, mas precisávamos entregar agora". Embora pesquisadores venham estudando há muito tempo essas notas no código principal que executa um programa, eles têm ignorado amplamente as notas encontradas no código usado para testar esse programa. Isso é uma omissão significativa, pois se os próprios testes forem falhos ou mal escritos, todo o sistema de software torna-se não confiável.

Uma equipe de pesquisadores da Universidade de Manitoba partiu para entender essa camada oculta de dívida. Eles se concentraram em um tipo específico de software escrito em Java, uma linguagem amplamente utilizada para construir aplicações complexas. Para obter uma visão clara, eles reuniram uma coleção massiva de mais de um milhão de comentários de mil projetos de código aberto diferentes. Deste vasto conjunto, eles selecionaram aleatoriamente cinquenta mil comentários para examinar manualmente. Esta revisão manual foi um trabalho minucioso, exigindo que os pesquisadores lessem cada nota e decidissem se ela representava uma admissão genuína de um problema ou apenas uma explicação padrão. Após filtrar os comentários que não eram relevantes ou que vinham de um único projeto que distorcia os dados, eles identificaram 615 comentários que eram exemplos reais de dívida técnica em código de teste.

Os pesquisadores descobriram que a natureza dessas dívidas no código de teste é bastante diferente do que é encontrado no código da aplicação principal. Eles classificaram as 615 instâncias em onze categorias distintas. Algumas eram familiares, como notas sobre design ruim ou documentação ausente. No entanto, quatro categorias eram inteiramente novas e específicas do mundo dos testes. Estas incluíam "testes limitados", onde um desenvolvedor admite que o teste verifica apenas uma fatia minúscula e não representativa do problema; "testes pulados", onde um teste é explicitamente desativado porque não pode ser executado no ambiente atual; "em espera", onde um teste aguarda que uma ferramenta ou serviço externo esteja disponível; e "incerteza", onde o desenvolvedor não tem certeza se o teste está sequer correto. Essa taxonomia revelou que o código de teste carre vezes seus próprios fardos, frequentemente relacionados aos desafios específicos de validar o comportamento do software em vez de construí-lo.

Tendo mapeado como essas dívidas se parecem, a equipe fez uma segunda pergunta, mais prática: os computadores conseguem encontrá-las automaticamente? Eles testaram sete ferramentas existentes projetadas para detectar essas notas em código-fonte regular. Eles também testaram uma gama de modelos de inteligência artificial, incluindo tanto modelos de código aberto quanto sistemas proprietários poderosos de grandes empresas de tecnologia. Os resultados foram surpreendentes. As ferramentas existentes, que dependem da busca por palavras-chave específicas como "TODO" ou "FIXME", tiveram o melhor desempenho entre os métodos tradicionais, mas ainda perderam mais de um terço das dívidas reais. Elas eram boas em estar corretas quando encontravam algo, mas falhavam em encontrar muitos dos problemas reais.

Os modelos de inteligência artificial tiveram um desempenho ainda pior de maneiras diferentes. Os modelos de código aberto tiveram dificuldade em encontrar as dívidas, muitas vezes falhando em reconhecê-las, a menos que as notas contivessem palavras-chave muito óbvias. Quando encontravam algo, eram frequentemente errados. Os modelos proprietários, que são geralmente considerados mais avançados, mostraram o problema oposto. Eles encontraram quase todas as dívidas, mas também sinalizaram centenas de comentários inofensivos como problemas. Eles estavam tão ansiosos para encontrar questões que confundiram explicações rotineiras com admissões de falha. No fim, nem as ferramentas tradicionais nem os sistemas de IA mais avançados puderam detectar essas dívidas no código de teste de forma confiável.

O estudo conclui que a maneira como os desenvolvedores escrevem sobre problemas no código de teste é fundamentalmente diferente de como escrevem sobre problemas no código principal. As notas em arquivos de teste frequentemente utilizam linguagem específica do processo de teste, como mencionar que um teste está "desativado" ou "pulado", o que as ferramentas padrão e os modelos de IA não reconhecem como um sinal de dívida. Os pesquisadores descobriram que os métodos atuais ainda não estão prontos para lidar com essa complexidade. Eles criaram um novo conjunto de dados e um mapa detalhado desses tipos de dívida para ajudar futuros pesquisadores a construir melhores ferramentas de detecção. Até lá, a tarefa de encontrar e corrigir essas falhas ocultas no código de teste continua sendo um trabalho que requer atenção humana.