Software testen: Lass die KI mal machen
Software testen mit Unit-Tests, Teil 1
Was können GitHub Copilot, ChatGPT, Microsoft Copilot, DeepSeek und Konsorten heute tatsächlich? Klar ist, die Ergebnisse einer noch so intensiven Befragung der künstlichen Helferlein bedürfen sorgfältiger Kontrolle. Um aber mal einen groben Überblick über die Fähigkeiten der gängigen Test-Frameworks zu bekommen, ist ein naiver Ansatz womöglich geeignet.
Die Quelltexte finden Sie im GitHub-Repository zu diesem Artikel im Branch „KI“.
Ein erster Prompt
Lassen wir GitHub Copilot mal ganz unbefangen ein paar Tests generieren. Ein einfacher Prompt lautet so:
Schreibe Unit-Tests für die Klasse Calculator.cs. Schließe Grenzfälle mit ein und beachte ebenfalls, dass bestimmte Werte zu Exceptions führen können. Benutze xUnit als Testframework.
Die zu testende Klasse implementiert die Schnittstelle aus Listing 1.
Listing 1: Die ICalculator-Schnittstelle
public interface ICalculator
{
int Add(int a, int b);
int Subtract(int a, int b);
int Multiply(int a, int b);
int Divide(int a, int b);
} So ganz zufrieden kann man mit dem Ergebnis nicht sein: Sämtliche möglichen Überschreitungen des Wertebereichs eines Int32 wurden nicht bedacht. Lediglich die Division durch null wurde als Grenzfall erkannt. Ihre Kollegen würden Ihnen Ihren Feature-Branch im Review um die Ohren hauen angesichts der nicht beachteten Akzeptanzkriterien.
Gnade vor Recht
Nun gut, noch lange kein Grund, irgendwelche künstlich intelligenten Copiloten zu verteufeln. Wagen wir einen Versuch mit ChatGPT und NUnit.
Schreibe Unit-Tests für die Klasse Calculator.cs, die die Schnittstelle ICalculator.cs implementiert. Schließe Grenzfälle mit ein und beachte ebenfalls, dass bestimmte Werte zu Ausnahmen führen können. Beachte ebenso die Wertebereiche einer 32-Bit-Ganzzahl. Leite die Test-Methoden-Namen von den Methodennamen der Schnittstelle ab. Benutze NUnit als Testframework. Und dies ist die Schnittstelle: [siehe Listing 1]
Positiv fällt auf, dass nun auch der gültige Wertebereich beachtet wird. Störend ist nur, dass ChatGPT hier nicht weiß (und auch nicht wissen kann), dass die Version 4.x von NUnit verwendet werden soll, die hat keine Assert.AreEqual-Methode. Hier hätte ClassicAssert.AreEqual verwendet werden müssen. Das ließe sich allerdings mit GitHub Copilot schnell beheben. Außerdem bietet ChatGPT hier direkt an, TestCase-Attribute zu verwenden, um Tests zusammenzufassen.
Geben wir Microsofts Copilot mal eine Chance
Um keine bösen Überraschungen zu erleben, wird der Prompt noch genauer formuliert:
Schreibe Unit-Tests für die Klasse Calculator.cs, die die Schnittstelle ICalculator.cs implementiert. Schließe Grenzfälle mit ein und beachte ebenfalls, dass bestimmte Werte zu Ausnahmen führen können. Beachte ebenso die Wertebereiche einer 32-Bit-Ganzzahl. Leite die Test-Methoden-Namen von den Methodennamen der Schnittstelle ab. Benutze MSTest, Version ^3.6, als Testframework. Und dies ist die Schnittstelle: [siehe Listing 1]
Hier lässt sich das Ergebnis kompilieren, im Gegensatz zum vorherigen Versuch. Ebenso positiv ist zu bemerken, dass sowohl ChatGPT als auch Microsoft Copilot beachtet haben, dass der minimale Wert einer 32-Bit-Ganzzahl vom absoluten Betrag her um eins größer ist als der maximale Wert. Folglich löst die Division eines Int32.MinValue durch -1 eine Ausnahme aus, was auch überprüft wird:
public void Divide_MinValueByMinusOne_ShouldThrowOnOverflow()
{
Assert.Throws<OverflowException>(() => _calculator.Divide(int.MinValue, -1));
}
Zunächst musste sich der Autor wundern, dass keine der Testmethoden, die eine Overflow Exception hätten auslösen sollen, dies auch getan haben. Und noch mehr wundern musste sich der Autor über die Tatsache, dass die verwendeten Projektvorlagen nicht so konfiguriert sind, dies auch zu tun. Erst der Haken bei Auf arithmetischen Überlauf prüfen bewirkte, dass alle Tests erfolgreich durchgeführt wurden (Bild 1).
Ausnahmen wurden nicht ausgelöst (Bild 1)
AutorFazit
Wie eingangs angedeutet, bedürfen die Ergebnisse der künstlichen Assistenten einer genaueren Überprüfung. Der Autor möchte behaupten, bei dieser trivialen Aufgabe mit manueller Konstruktion der Tests schneller gewesen zu sein als die bemühten Maschinen. Ein grundsätzliches tiefes Misstrauen gegenüber allem, was auch nur ansatzweise behauptet, klüger als der Benutzer zu sein, hat bisher verhindert, tiefer in die Materie eingestiegen zu sein. Auch aus rein empirischer Sicht wagt der Autor zu behaupten, dass es meistens schiefgeht, wenn die digitalen Besserwisser meinen, es wirklich besser zu wissen. Dennoch soll hier nicht ausgeschlossen werden, dass bei entsprechend komplexen Aufgaben durchaus brauchbare Ergebnisse erzielt werden können. Berührungsängste sind nicht angebracht, aber ein gesundes Misstrauen gepaart mit sehr genauer Untersuchung der Ergebnisse ist absolut notwendig.
