Wir erwarten von Unit-Tests, dass sie die Korrektheit geänderter Logik prüfen und helfen, unbeabsichtigte Änderungen im Verhalten der Anwendung aufzuspüren. Bei der Entwicklung mit KI ist es außerdem wichtig zu prüfen, ob Funktionalität außerhalb des Task-Umfangs unversehrt bleibt.
Zu prüfen, ob eine neue Funktion funktioniert, ist daher nur ein Teil der Arbeit. Wir müssen auch kontrollieren, dass die Änderung bestehende Regeln der Anwendung nicht gebrochen hat.
Was Unit-Tests schützen sollten
Unit-Tests prüfen das Verhalten einzelner Teile des Codes. Sie dienen zugleich als Schutz vor Regressionen, also Fehlern, die entstehen, wenn Verhalten geändert wird, das zuvor funktionierte.
Dieser Schutz ist bei KI-generiertem Code besonders wertvoll. Die KI kann eine konkrete Anforderung erfüllen und dabei zugleich Logik verändern, die unangetastet bleiben sollte.
Gut gestaltete Tests helfen, die Grenzen einer Änderung festzulegen:
Dieses Verhalten wollen wir ändern. Diese Regeln müssen weiterhin gelten.
Nach Risiko und tatsächlichen Abhängigkeiten testen
Wir müssen nicht automatisch für jeden Getter, Setter oder jede einfache Datenklasse einen eigenen Test schreiben.
Ein Test, der lediglich die Implementierung wiederholt, kann die Zahl der Tests erhöhen, ohne viel Wert hinzuzufügen. Außerdem verursacht er bei weiteren Änderungen mehr Wartungsaufwand.
Eine praktische Regel lautet:
Konzentrieren Sie sich bei einer konkreten Änderung auf das geänderte Verhalten und die Teile der Anwendung, die davon abhängen. Den Testumfang bestimmen Sie nach der möglichen Auswirkung.
Bei einfachen Methoden ohne Entscheidungslogik kann ein separater Unit-Test überflüssig sein, wenn andere Tests ihr Verhalten angemessen abdecken.
Einfachheit allein ist jedoch kein Grund anzunehmen, dass die KI keinen Fehler macht. Selbst eine einzeilige Methode kann den Preis einer Bestellung oder die Zugriffsrechte eines Benutzers bestimmen.
Bevor Sie einen Test hinzufügen, stellen Sie drei Fragen:
- Welches Verhalten ändert sich in diesem Task?
Wir prüfen, ob die Änderung die Anforderungen erfüllt.
- Welche Regeln und abhängigen Komponenten müssen unversehrt bleiben?
Wir suchen Stellen, an denen die Änderung eine Regression verursachen könnte.
- Wird der Test einen echten Fehler aufdecken?
Wir prüfen das erwartete Verhalten, statt einfach die Implementierung zu kopieren.
Tests müssen mit der Geschäftslogik verbunden sein
Die wertvollsten Unit-Tests schützen konkrete Regeln der Anwendung.
Bei einer Methode zur Rabattberechnung reicht es zum Beispiel nicht zu prüfen, dass sie eine Zahl zurückgibt. Wir müssen wissen, ob diese Regeln weiterhin gelten:
der Rabatt überschreitet nicht die zulässige Grenze;
der Endpreis fällt nicht unter null;
ein Kunde, der keinen Anspruch auf Rabatt hat, zahlt den vollen Preis;
die Berechnung folgt den definierten Rundungsregeln.
Die Verbindung zwischen einer Methode und einer Geschäftsregel gibt einem Test seinen Zweck.
Die Implementierung kann sich ändern. Eine Regel außerhalb des beabsichtigten Task-Umfangs muss unversehrt bleiben.
Wie AITM dies angeht
AITM verbindet die KI-Entwicklung mit Projektkontext, Contracts und Abhängigkeiten zwischen verschiedenen Teilen der Anwendung.
Vor der Implementierung ermittelt der Architect, was sich ändern soll, wie die betroffenen Teile zusammenhängen und welche Regeln unversehrt bleiben müssen. Der Test-Schritt nutzt dann diese Informationen.
Die entscheidende Frage ist daher mehr als die, ob die KI einen Test schreiben kann. Es geht darum, ob die KI weiß, was der Test schützen soll und warum.
Nehmen wir eine Änderung an DiscountService.calculateDiscount(). Wenn der Contract mit dependsOnModules festhält, dass auch OrderSummary.render() von der Rabattberechnung abhängt, hat der Test-Schritt einen Grund, auch die Auswirkung auf die Bestellübersicht zu prüfen.
Die Berechnung selbst lässt sich mit einem Unit-Test prüfen. Für die Prüfung, wie die Berechnung mit der Bestellübersicht zusammenspielt, kann ein Integrationstest besser geeignet sein.
Tests werden daher rund um die tatsächlichen Abhängigkeiten und Risiken der konkreten Änderung entworfen.
Zehn Tests für einen Task, zweitausend für einen anderen
Nicht jeder Task braucht denselben Testumfang.
Zur Veranschaulichung: In einem Projekt mit 32.467 Tests kann eine kleine Änderung die Ausführung von zehn relevanten Tests erfordern. Eine Änderung an gemeinsam genutzter Geschäftslogik kann zweitausend erfordern.
Der Zweck gezielten Testens ist es, Tests auszuwählen, die das geänderte Verhalten und seine Abhängigkeiten abdecken. Das kann den Feedback-Zyklus verkürzen und die Verifikation auf die Risiken des Tasks konzentrieren.
Umfassendere Regressionsprüfungen oder eine vollständige Test-Suite haben bei umfangreichen Änderungen oder vor einem neuen Release weiterhin ihren Platz.
Die Zahl der ausgeführten Tests sollte der Auswirkung der Änderung entsprechen.
Wenn ein Test fehlschlägt, müssen wir verstehen, warum
Ein fehlschlagender Test deutet nicht immer auf dasselbe Problem hin. Wir müssen zwischen diesen Situationen unterscheiden:
in der Implementierung wurde ein Fehler eingeführt;
die Änderung hat unbeabsichtigt eine bestehende Geschäftsregel verletzt;
eine neue Funktion hat das erwartete Verhalten absichtlich geändert, und der Test muss angepasst werden.
Die Anforderungen des Tasks, die Contracts und die Beschreibungen der Geschäftslogik liefern den Kontext für diese Beurteilung.
Wenn sich eine Anforderung legitim geändert hat, muss sich auch der entsprechende Test ändern. Wenn die KI eine Regel verletzt hat, die unversehrt hätte bleiben sollen, muss die Implementierung korrigiert werden.
Einen Test einfach so zu ändern, dass er wieder besteht, könnte einen echten Fehler verbergen.
Unit-Tests sind die erste Schutzschicht
Jede Teststufe hat eine andere Rolle:
Unit-Tests prüfen einzelne Teile der Logik.
Integrationstests prüfen, wie Module und Systeme zusammenarbeiten.
E2E-Tests prüfen vollständige Benutzerabläufe in einer laufenden Anwendung.
Diese Schichten ergänzen einander. Jede fängt andere Arten von Fehlern ab und hilft, eine Änderung aus einer anderen Perspektive zu verifizieren.
Bei der Entwicklung mit KI prüfen wir daher zwei Dinge: ob der Task erledigt wurde und ob das Verhalten außerhalb des beabsichtigten Umfangs unversehrt geblieben ist.
Die Verbindung von Task-Anforderungen, Geschäftslogik, Abhängigkeiten und Tests ist ein wichtiger Teil der AITM-Orchestrierung.
Z. B. Unit-Tests
Mehr erfahren Sie unter https://www.aitm.cz
#AITM #UnitTesting #SoftwareTesting #AI #SoftwareDevelopment