Metas Tool zur Verbesserung automatisierter Unit-Tests mit großen Sprachmodellen: TestGen-LLM

Metas Tool zur Verbesserung automatisierter Unit-Tests: TestGen-LLM

• Das von Meta entwickelte Tool TestGen-LLM nutzt große Sprachmodelle (Large Language Models, LLMs), um bestehende, von Menschen geschriebene Tests automatisch zu verbessern.
• Die von TestGen-LLM generierten Testklassen bestehen erfolgreich eine Reihe von Filtern, die im Vergleich zur ursprünglichen Testsuite eine messbare Verbesserung garantieren und das LLM-Halluzinationsproblem vermeiden.
• Der Einsatz von TestGen-LLM in den Test-a-thons für die Instagram- und Facebook-Plattformen von Meta wird erläutert.

Leistungsbewertung von TestGen-LLM

• In der Bewertung der Instagram-Produkte Reels und Stories wurden 75% der Testfälle von TestGen-LLM korrekt gebaut, 57% bestanden zuverlässig und 25% erhöhten die Abdeckung.
• In den Test-a-thons von Meta für Instagram und Facebook verbesserte TestGen-LLM 11,5% aller angewandten Klassen, und Meta-Softwareingenieure akzeptierten 73% der Empfehlungen für die Bereitstellung.
• Dies ist der erste Bericht über den großskaligen Einsatz von von LLM-generiertem Code und die damit verbundene Zusicherung, dass die Codequalität verbessert wird.

GN⁺-Meinung

• TestGen-LLM ist ein Tool, das im Bereich der Softwaretestautomatisierung und -qualitätssteigerung eine Revolution einleiten könnte, da es bestehende Tests erfolgreich mit großen Sprachmodellen verbessert.
• Es trägt in realen Produktionsumgebungen zur Erhöhung der Testabdeckung bei und generiert dabei zuverlässige Testfälle, womit es einen wichtigen Beitrag für die Software Engineering-Community leistet.
• Der erfolgreiche Einsatz von TestGen-LLM in den Test-a-thons von Meta zeigt, dass eine Integration in die tatsächliche Produktentwicklung möglich ist und dies eine wichtige Entwicklung zur Verbesserung von Effizienz und Stabilität in der Softwareentwicklung darstellt.

[GN⁺]

Hacker News-Kommentar

• In einem großen Versicherungsunternehmen haben Management und Team Leads ein Ziel von 80 % Testabdeckung für die gesamte Codebasis festgelegt. Daraufhin begannen die Entwickler, einfache Unit-Tests für die Getter und Setter von Java-DTOs zu schreiben, um dieses Ziel zu erreichen. Als ich damals noch ein junger Entwickler war, zeigte mir diese Erfahrung, dass die ausschließliche Fokussierung auf KPIs ein Verhalten erzeugen kann, das nicht mit dem eigentlichen Ziel übereinstimmt. Einige wenige gut durchdachte E2E-Test-Szenarien hätten die Softwarequalität deutlich stärker verbessert.
• Ein Problem von von LLMs generierten Tests ist, dass sie eher dazu neigen, fehlerhaftes Verhalten zu „zulassen“. Das ist besonders wahrscheinlich, wenn die Testabdeckung der Codebasis niedrig ist. Bei manuell geschriebenen neuen Tests gibt es jemanden, der einschätzen kann, ob ein Fehler im System liegt oder der Test falsch ist. Solche Tests sollten mindestens in einem separaten Testordner mit einem gesunden Maß an Skepsis behandelt werden.
• Wenn man das PDF liest, scheint es vor allem darum zu gehen, stabil immer wieder bestandene Tests zu erzeugen. Der Hauptzweck ist offenbar, eine Regression-Test-Suite aufzubauen, die das bestehende Verhalten des Codes festschreibt. Das ersetzt nicht die von Entwicklern geschriebenen Tests; bei diesen geht man davon aus, dass sie die funktionalen Anforderungen kennen.
• Vor rund 20 Jahren habe ich in einem Unternehmen AgitarOne ausprobiert. Es versprach, automatisch Testfälle für Java-Code zu generieren, um dessen Verhalten zu erkunden. Agitar konnte aber ebenfalls automatisch Tests erzeugen, die bestanden wurden, und diese auch als Regression-Suite nutzen. Persönlich hat mir das nicht gefallen. Das Management war der Meinung, dass höhere Testabdeckung automatisch bessere Qualität bedeute. Ich frage mich, wie viel besser der LLM-Ansatz im Vergleich zu Agitar tatsächlich ist.
• Testen ist grundsätzlich eine gute Methode, um Codequalität einzuschätzen. Wenn Tests kompliziert sind oder das Erreichen der Zielabdeckung schwierig ist, besteht wahrscheinlich Bedarf, den betreffenden Code zu verbessern.
• Bei unlogged.io haben wir eine Zeit lang darauf gesetzt, automatisch JUnit-Tests zu generieren. Aus verschiedenen Gründen hat dieser Ansatz nicht funktioniert: 1) zu viel generierter Testcode, den Entwickler nicht pflegen wollen, 2) Tests, die reale Szenarien aus der echten Welt nicht simulieren, 3) Codeabdeckung als Eitelkeitsmetrik. Jetzt konzentrieren wir uns darauf, No-Code-Replay-Tests zu liefern, die alle einzigartigen Produktion-Szenarien simulieren. Zur Einordnung: Ich bin Mitgründer von unlogged.io.
• Im Gegenteil möchte ich den Prozess umkehren: Anforderungen als Eingangsdaten liefern, daraus Tests generieren, die diese prüfen, und nur Code erzeugen, der die Tests besteht. Mit Copilot kommt man in begrenztem Maße manchmal in diese Richtung, aber ich frage mich, warum sich kaum jemand auf diesen Ansatz fokussiert.
• TestGen-LLM ist ein seltsames Gebilde. Es kann als erster Schritt für Refactoring oder Rewrite dienen, doch die Betonung der Codeabdeckung im Paper wirkt völlig verfehlt. Wenn ein Unternehmen bereits so weit ist, hohe Abdeckung um jeden Preis zu verlangen, kann es hilfreich sein. TestGen-LLM wird den Projektcode aber auf keine Weise verbessern und eher zusätzliche Reibung beim Umsetzen echter Verbesserungen erzeugen. TestGen-LLM, das auf Compilerfehlern und fehlgeschlagenen Tests basiert, um LLM-Müll auszufiltern, wäre deutlich nützlicher, wenn es Edge-Case-Tests erzeugt, die mal bestehen und mal scheitern. Da im Paper keine Beispiele generierter Tests enthalten sind, vermute ich, dass sie, wie der übrige LLM-generierte Code, den ich gesehen habe, eher amateurhaft sind.
• Ich frage mich, wie viel es kosten wird, in Zukunft einen riesigen Korpus automatisch generierter Tests zu pflegen. Es braucht ja nicht nur einen Weg, Testfälle zu erzeugen, sondern auch automatisierte Verfahren zu ihrer Aktualisierung.
• Dass Mitarbeitende von Meta ein 12-seitiges Paper veröffentlicht haben, um AI für Entwickler zu promoten, finde ich bemerkenswert. Sie haben sogar ein Sankey-Diagramm verwendet. Vielleicht liege ich falsch, aber bei so einem Ansatz sollte man reproduzierbare Informationen liefern, oder nicht? Meta braucht Trainingsdaten. Vielleicht ist etwas davon deshalb auch veröffentlicht worden.
• In der Evaluation für Instagrams Reels- und Stories-Produkte waren 75 % der Testfälle von TestGen-LLM korrekt aufgebaut, 57 % bestanden verlässlich und 25 % erhöhten die Abdeckung. Das Ergebnis wirkt dadurch nicht besonders überzeugend.