Meta melhora testes unitários automatizados com modelos de linguagem de larga escala

Ferramenta da Meta para melhorar testes unitários automatizados: TestGen-LLM

• A ferramenta TestGen-LLM, desenvolvida pela Meta, usa modelos de linguagem de larga escala (LLMs) para melhorar automaticamente testes existentes escritos por humanos.
• As classes de teste geradas pelo TestGen-LLM passaram com sucesso por uma série de filtros que garantem melhorias mensuráveis em relação à suíte de testes original, resolvendo o problema de alucinação de LLM.
• O texto descreve a implantação do TestGen-LLM em test-a-thons de teste para as plataformas Instagram e Facebook da Meta.

Avaliação de desempenho do TestGen-LLM

• Na avaliação para os produtos Reels e Stories do Instagram, 75% dos casos de teste do TestGen-LLM foram compilados corretamente, 57% passaram com confiabilidade e 25% aumentaram a cobertura.
• Nos test-a-thons de teste do Instagram e Facebook da Meta, o TestGen-LLM melhorou 11,5% de todas as classes aplicadas, e os engenheiros de software da Meta aceitaram 73% das recomendações para implantação em produção.
• Este é o primeiro relatório sobre a implantação em escala industrial de código gerado por LLM com essas garantias de melhoria de código.

Opinião da GN⁺

• O TestGen-LLM é uma ferramenta que pode trazer inovação para a automação e a melhoria da qualidade de testes de software, tendo sucesso ao melhorar testes existentes com modelos de linguagem de larga escala.
• A ferramenta contribui significativamente para a comunidade de engenharia de software ao aumentar a cobertura de testes e gerar casos de teste confiáveis em cenários de produção reais.
• A adoção bem-sucedida no test-a-thon da Meta mostra que o TestGen-LLM tem potencial para ser integrado ao desenvolvimento de produtos reais, representando um avanço importante para melhorar a eficiência e a estabilidade do desenvolvimento de software.

[GN⁺]

Opinião do Hacker News

• Em uma grande seguradora, os gestores estabeleceram a meta de 80% de cobertura de testes para toda a base de código. Como consequência, os desenvolvedores começaram a escrever testes unitários simples para getters e setters de DTOs Java para atingir essa meta. Como desenvolvedor júnior, essa experiência me mostrou que focar somente em KPI pode incentivar comportamentos que não combinam com o objetivo pretendido. Alguns cenários de testes E2E bem pensados teriam tido um impacto muito melhor na qualidade do software.
• Um problema dos testes gerados por LLM é a alta chance de "aprovar" comportamento com bug, especialmente quando a cobertura de testes da base de código é baixa. Quando se escreve um teste novo manualmente, há alguém para decidir se o sistema é que está com defeito ou se o teste está errado. Pelo menos esses testes deveriam ficar separados em uma pasta de testes própria e tratados com um nível adequado de ceticismo.
• Lendo o PDF, parece que isso é apenas gerar testes que passam de forma repetitiva, ou seja, testes estáveis. O objetivo principal é criar uma suíte de testes de regressão que fecha o comportamento do código existente. Isso não substitui testes escritos por desenvolvedores, porque esperamos que testes escritos por desenvolvedores já conheçam os requisitos funcionais.
• Há cerca de 20 anos, trabalhei em uma empresa onde testamos o AgitarOne. Ele prometia gerar automaticamente casos de teste para código Java e ajudar a explorar esse comportamento. Mas o Agitar também conseguia gerar testes que passavam automaticamente, e esses podiam ser usados como suíte de regressão. Pessoalmente, eu não gostei disso. Os gestores achavam que mais cobertura de testes significava maior qualidade. Fiquei curioso sobre o quanto a abordagem de LLM é melhor do que o Agitar.
• Escrever testes é normalmente uma ótima maneira de avaliar a qualidade do código. Se escrever testes é complicado ou atingir cobertura é difícil, é mais provável que o código em teste precise de melhorias.
• A unlogged.io ficou um tempo focada em gerar testes junit automaticamente. A abordagem não teve sucesso por vários motivos: 1) muitos códigos de teste gerados que os desenvolvedores não querem manter, 2) testes gerados que não simulam cenários do mundo real, 3) cobertura de código como métrica de vaidade. Atualmente, estamos focados em fornecer testes de replay no-code para simular todos os cenários únicos de produção. Apenas como nota, sou o fundador da unlogged.io.
• Pelo contrário, eu queria uma abordagem inversa. Inserir critérios de aceitação, gerar testes que os validem, e então gerar apenas o código que passe nesses testes. Com o Copilot, algumas vezes se pode chegar perto disso de maneira limitada, mas fico em dúvida de por que parece que ninguém se concentra nisso.
• O TestGen-LLM é uma criação estranha. Acho que pode ser usado como etapa inicial para refatoração ou reescrita, mas a ênfase em cobertura de código no artigo parece totalmente absurda. Se a organização já estiver doida o suficiente para exigir cobertura alta, talvez faça sentido, porém o TestGen-LLM não melhora o código de projeto em nada e ainda vai aumentar o atrito para implementar melhorias reais. Confiar em erros de compilação e testes com falha para filtrar LLM lixo faz com que o TestGen-LLM fosse bem mais útil gerando testes de edge cases que podem ou não passar. Como não há exemplos de testes gerados no artigo, suspeito que eles sejam amadores como o restante do código gerado por LLM que já vi.
• Fico curioso de quanto custará manter um corpus gigantesco de testes gerados automaticamente no futuro. Não basta só gerar casos, também é preciso oferecer uma forma automatizada de atualizá-los.
• Achando interessante que funcionários da Meta tenham lançado um paper de 12 páginas para promover IA para desenvolvedores. Eles chegaram a usar um diagrama de Sankey. Talvez eu esteja errado, mas se o anuncio acontece nesse formato, não deveria haver reprodução da informação para validar as alegações. A Meta precisa de dados para treinar. Então talvez tenha sido por isso que publicaram algo.
• Na avaliação de Reels e Stories do Instagram, 75% dos casos de teste do TestGen-LLM foram construídos corretamente, 57% passaram com confiabilidade e 25% aumentaram a cobertura. Isso me pareceu um resultado nada animador.