Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation

Diese umfassende Studie stellt die erste groß angelegte empirische Evaluation von LLM-generierten Unit-Tests auf Klassenebene dar und zeigt, dass zwar reasoning-basierte Prompting-Techniken wie GToT die Zuverlässigkeit und Lesbarkeit verbessern, jedoch hohe Kompilierungsfehlerquoten und Halluzinationen hybride Ansätze mit automatischer Validierung und Suchbasierten Methoden für den produktiven Einsatz notwendig machen.

Das Wesentliche

Stellen Sie sich vor, Sie müssen ein riesiges, komplexes Haus bauen. Bevor Sie die ersten Steine setzen, müssen Sie einen Plan erstellen, der genau beschreibt, wie jedes Zimmer, jede Treppe und jedes Fenster funktionieren muss. In der Softwareentwicklung nennt man diese Pläne Tests. Sie stellen sicher, dass das Programm später nicht zusammenbricht, wenn man es benutzt.

Das Problem: Das manuelle Schreiben dieser Pläne ist extrem langweilig, zeitaufwendig und wird oft vernachlässigt. Früher gab es Roboter (wie EvoSuite), die diese Pläne automatisch schrieben. Diese Roboter waren sehr effizient und deckten jeden Winkel des Hauses ab, aber ihre Pläne waren oft unleserlich, wie eine verschlüsselte Nachricht, die nur ein Computer versteht, aber kein Mensch.

Jetzt kommen die Künstlichen Intelligenzen (LLMs) ins Spiel. Sie sind wie hochintelligente, kreative Architekten, die Pläne schreiben können, die Menschen verstehen und lieben. Aber: Können sie das wirklich gut? Und wie können wir sie am besten anweisen?

Diese Studie ist wie ein riesiger, wissenschaftlicher Wettbewerb, bei dem vier verschiedene KI-Architekten (GPT-3.5, GPT-4, Mistral und Mixtral) gegen den alten Roboter (EvoSuite) antreten. Die Forscher haben den KIs verschiedene Arten von Anweisungen (sogenanntes Prompt Engineering) gegeben, um zu sehen, welche Methode die besten Test-Pläne liefert.

Hier ist die einfache Zusammenfassung der Ergebnisse, verpackt in ein paar anschauliche Metaphern:

1. Die Anweisung macht den Unterschied (Prompt Engineering)

Stellen Sie sich vor, Sie geben einem Koch eine Bestellung auf.

• Zero-Shot (ZSL): Sie sagen nur: "Mach mir ein Essen." Der Koch versucht es, aber das Ergebnis ist oft chaotisch.
• Chain-of-Thought (CoT): Sie sagen: "Überlege erst Schritt für Schritt, welche Zutaten du brauchst, dann koche." Das Ergebnis ist besser.
• Guided Tree-of-Thought (GToT): Das ist der Gewinner! Sie sagen: "Stellen Sie sich drei Experten vor, die gemeinsam brainstormen, Fehler suchen und dann den perfekten Plan erstellen."

Ergebnis: Die KI, die so angeleitet wurde (GToT), schrieb die klarsten und strukturiertesten Pläne. Sie waren lesbarer als die des alten Roboters und sogar besser als bei einfachen Befehlen.

2. Der "Halluzinations"-Effekt

KIs sind manchmal wie sehr selbstbewusste, aber vergessliche Architekten. Sie schreiben Pläne, die perfekt aussehen, aber auf nicht existierenden Materialien basieren.

• Die KI erfindet Funktionen oder Bibliotheken, die es gar nicht gibt (wie "Ich baue eine Treppe aus unsichtbarem Glas").
• In der Studie war das ein riesiges Problem: Bis zu 86 % der von der KI geschriebenen Tests ließen sich nicht einmal kompilieren (also nicht in eine ausführbare Datei umwandeln), weil sie auf diesen erfundenen Dingen basierten.
• Der alte Roboter (EvoSuite) machte hier viel weniger Fehler, war aber in der Lesbarkeit schlechter.

3. Lesbarkeit vs. Zuverlässigkeit

• Die KI-Tests waren wie ein gut geschriebenes Buch: Schön zu lesen, mit klaren Überschriften und logischem Aufbau. Ein menschlicher Entwickler würde sie gerne lesen und verstehen.
• Die Roboter-Tests (EvoSuite) waren wie eine technische Zeichnung: Extrem präzise und deckten fast alles ab (hohe "Abdeckung"), aber für einen Menschen schwer zu entschlüsseln.

Das Dilemma: Die KI schreibt schöne Pläne, aber sie sind oft nicht sofort einsatzbereit, weil sie "Halluzinationen" enthalten. Der Roboter schreibt hässliche Pläne, die aber fast immer funktionieren.

4. Die "Test-Gerüche" (Test Smells)

Stellen Sie sich vor, ein Haus hat einen Geruch. Ein "Test-Geruch" ist ein schlechtes Design in einem Test.

• Magische Zahlen: Die KI schrieb oft Tests mit Zahlen ohne Erklärung (z. B. "Warte 15 Sekunden" statt "Warte, bis der Kaffee fertig ist"). Das macht den Code schwer zu warten.
• Roulette der Behauptungen: Die KI stellte viele Behauptungen auf, ohne zu sagen, was sie prüfen. Das ist wie ein Richter, der "Schuldig" ruft, ohne zu sagen, warum.

Die KI war hier oft besser als der Roboter, aber immer noch nicht perfekt.

Das große Fazit: Ein Team ist besser als ein Einzelkämpfer

Die Studie kommt zu einem klaren Schluss: Die KI ist noch nicht bereit, den Roboter komplett zu ersetzen.

• Die KI ist der kreative Assistent: Sie schreibt Tests, die Menschen verstehen können, und ist großartig darin, die Struktur und Lesbarkeit zu verbessern.
• Der Roboter (EvoSuite) ist der strengere Prüfer: Er findet mehr Fehler und ist zuverlässiger, aber seine Ergebnisse sind schwer zu lesen.

Die Lösung? Ein Hybrid-Ansatz.
Stellen Sie sich vor, die KI schreibt den Entwurf für das Haus (weil sie es schön und verständlich macht), und der Roboter überprüft dann, ob alle Steine wirklich passen und das Haus steht (weil er auf Zuverlässigkeit und Abdeckung spezialisiert ist).

Zusammenfassend: Künstliche Intelligenzen können uns beim Schreiben von Software-Tests enorm helfen, indem sie die Tests für Menschen lesbarer machen. Aber wir müssen sie noch wie einen Lehrling behandeln: Wir müssen ihre Arbeit genau prüfen, die erfundenen Details korrigieren und sie mit bewährten Methoden kombinieren, bevor wir ihnen das volle Vertrauen schenken.

Technische Zusammenfassung

Hier ist eine detaillierte technische Zusammenfassung des Papers „Prompt Engineering in LLMs for Automated Unit Test Generation: A Large-Scale Study" auf Deutsch:

1. Problemstellung

Das manuelle Erstellen von Unit-Tests ist zeitaufwendig und wird oft vernachlässigt, was zu Lücken in der Testabdeckung und Softwarezuverlässigkeit führt. Traditionelle Ansätze wie die Search-Based Software Testing (SBST) (z. B. das Tool EvoSuite) optimieren zwar die Code-Abdeckung, erzeugen jedoch Tests, die oft schwer lesbar, schlecht strukturiert und schwer zu warten sind.

Large Language Models (LLMs) bieten vielversprechende Alternativen, da sie Tests mit natürlicherer Syntax und besserer Lesbarkeit generieren können. Bisherige Studien haben jedoch folgende Lücken:

• Fehlende umfassende Evaluation über verschiedene Prompting-Strategien hinaus (meist nur Zero-Shot).
• Unzureichende Bewertung der strukturellen Korrektheit und der direkten Nutzbarkeit (Extrahierbarkeit) der generierten Tests.
• Mangelnde Vergleichbarkeit mit etablierten SBST-Tools auf Klassenebene (statt nur Methodenebene) unter Berücksichtigung von Halluzinationen und Test-Smells.

2. Methodik

Die Studie führt eine groß angelegte empirische Evaluation durch, um die Leistungsfähigkeit von LLMs bei der Generierung von Unit-Tests auf Klassenebene zu untersuchen.

• Modelle: Vier State-of-the-Art-LLMs wurden verglichen:
  • GPT-3.5-turbo (OpenAI)
  • GPT-4 (OpenAI)
  • Mistral 7B (MistralAI)
  • Mixtral 8x7B (MistralAI)
• Prompting-Techniken: Fünf verschiedene Strategien wurden evaluiert:
  1. Zero-Shot Learning (ZSL)
  2. Few-Shot Learning (FSL)
  3. Chain-of-Thought (CoT)
  4. Tree-of-Thought (ToT)
  5. Guided Tree-of-Thought (GToT) (eine neuartige, vom Autor entwickelte Methode, die kollaboratives Denken simuliert).
• Datensätze: Drei diverse Datensätze wurden verwendet, um Generalisierbarkeit zu gewährleisten:
  • Defects4J: Reale Java-Projekte mit bekannten Fehlern.
  • SF110: Eine Sammlung von Java-Projekten mit existierenden Tests.
  • CMD (Custom Mini Dataset): Ein kuratiertes Dataset mit Projekten, die nach Mai 2023 veröffentlicht wurden, um Datenlecks durch Trainingsdaten der LLMs zu minimieren.
• Baseline: EvoSuite wurde als Referenz für SBST verwendet.
• Metriken:
  • Strukturelle Korrektheit: Match Success Rate (MSR) und Code Extraction Success Rate (CSR).
  • Kompilierbarkeit: Syntax-Checks und Kompilierungserfolg.
  • Qualität: Lesbarkeit (Scalabrino-Modell), Test-Smells (TsDetect), Code-Abdeckung (JaCoCo) und statische Analyse (Checkstyle, PMD, SpotBugs).
• Umfang: Insgesamt wurden 216.300 Testfälle generiert und analysiert.

3. Hauptbeiträge

1. Systematische Untersuchung von Prompt Engineering: Erster Vergleich von fünf Prompting-Strategien (inkl. GToT) über mehrere LLMs hinweg, der zeigt, dass strukturiertes Reasoning (CoT, GToT) die Testqualität signifikant verbessert.
2. Analyse der strukturellen Korrektheit und Extrahierbarkeit: Einführung und Anwendung von MSR/CSR-Metriken, um zu messen, wie gut generierter Code aus dem LLM-Ausgangstext extrahiert werden kann, bevor Syntax-Checks durchgeführt werden.
3. Unterscheidung von Lesbarkeit und Wartbarkeit: Die Studie zeigt, dass LLM-Tests zwar oft lesbarer sind als SBST-Tests, aber dennoch spezifische Test-Smells (wie „Magic Numbers" und „Assertion Roulette") aufweisen, die die Wartbarkeit beeinträchtigen.
4. Groß angelegte Evaluation: Vergleich von vier Modellen auf drei Datensätzen gegen EvoSuite, was eine breitere Generalisierbarkeit als frühere Studien ermöglicht.
5. Öffentliches Benchmark: Bereitstellung eines Replication Packages mit allen Daten, Prompts und Skripten.

4. Wichtige Ergebnisse

• Generierungsfähigkeit (RQ0): LLMs generieren fast immer eine Ausgabe (oft >90%), während EvoSuite in bestimmten komplexen Szenarien (z. B. Defects4J) manchmal keine Tests generiert.
• Format und Extrahierbarkeit (RQ1):
  • GToT ist die effektivste Strategie, um die Einhaltung von Prompt-Instruktionen (MSR) zu erzwingen.
  • OpenAI-Modelle (GPT-3.5, GPT-4) schneiden bei der Extrahierbarkeit (CSR) besser ab als Mistral-Modelle.
  • Few-Shot Learning (FSL) performt oft schlechter als erwartet.
• Syntax und Kompilierbarkeit (RQ2):
  • Kritischer Befund: Obwohl ca. 90% der LLM-Ausgaben syntaktisch korrekt sind, liegt die Kompilierbarkeit oft unter 10%.
  • Hauptursache sind Halluzinationen: Nicht existierende Symbole („Cannot Find Symbol"), falsche Importe und Zugriffsverletzungen.
  • EvoSuite erreicht fast 100% Kompilierbarkeit.
  • Reasoning-basierte Prompts (CoT, GToT) reduzieren Fehler, schließen die Lücke zu EvoSuite aber nicht.
• Lesbarkeit und Wartbarkeit (RQ3 & RQ4):
  • LLM-generierte Tests sind deutlich lesbarer als EvoSuite-Tests (Verbesserung um 21–40% in Lesbarkeits-Scores).
  • Reasoning-Prompts (CoT, GToT) verbessern die Lesbarkeit weiter.
  • Dennoch leiden LLM-Tests unter spezifischen Smells: Magic Number Tests sind in fast allen LLM-Tests (nahezu 100%) und EvoSuite-Tests vorhanden.
• Code-Abdeckung (RQ5):
  • EvoSuite übertrifft LLMs in der strukturellen Abdeckung (Zeilen, Anweisungen, Methoden) deutlich (EvoSuite ~94%, LLMs oft <50% bis 80% in Abhängigkeit vom Datensatz).
  • Reasoning-Prompts verbessern die Abdeckung der LLMs, erreichen aber nicht das Niveau von SBST.
• Test-Smells (RQ6):
  • Reasoning-Prompts reduzieren „Assertion Roulette" signifikant.
  • LLM-Tests sind oft „zustandslos" und haben weniger komplexe Smells als EvoSuite, leiden aber stark unter numerischen Literalen (Magic Numbers).

5. Bedeutung und Schlussfolgerungen

Die Studie zeigt, dass LLMs keine vollständigen Ersatz für traditionelle Testgenerierungstools wie EvoSuite sind, insbesondere wenn es um Zuverlässigkeit, Kompilierbarkeit und hohe Code-Abdeckung geht. Die Hauptprobleme liegen in der Halluzination von Abhängigkeiten und der Unfähigkeit, komplexe Projektstrukturen ohne manuelle Nachbearbeitung korrekt zu kompilieren.

Hauptempfehlungen:

1. Hybride Ansätze: Die Zukunft liegt in der Kombination von SBST (für Abdeckung und Robustheit) und LLMs (für Lesbarkeit, Wartbarkeit und Orakel-Design).
2. Prompt Engineering: Strukturierte Reasoning-Strategien wie GToT und CoT sind essenziell, um die strukturelle Qualität und Lesbarkeit zu verbessern, lösen aber nicht das Problem der Halluzinationen vollständig.
3. Rolle der Entwickler: LLMs sollten als assistive Werkzeuge betrachtet werden, die gut lesbare Test-Skelette liefern, die jedoch zwingend einer automatischen Validierung und menschlichen Prüfung unterzogen werden müssen, bevor sie in Produktionspipelines integriert werden können.

Die Arbeit liefert eine fundierte Basis für das Verständnis der aktuellen Grenzen und Möglichkeiten von LLMs im Software-Testing und unterstreicht die Notwendigkeit von Validierungsmechanismen in automatisierten Test-Generierungs-Pipelines.