Tests vom Handy, samt Abdeckungskriterien
Sechs Teststufen, Abdeckungskriterien von Anweisungen bis MC/DC und warum es ein Vorteil ist, die Ergebnisse am Handy zu haben.
Der Reiter Projekt → Tests ist nicht nur eine Liste dessen, was fehlschlägt. Es ist der Ort, an dem du Tests in Auftrag gibst, ihre Historie liest und von einem fehlgeschlagenen Fall bis zu dem durchklickst, was er eigentlich prüft — und das alles vom Handy, ohne eine einzige Zeile Prompt.
Stufen
Tests sind in sechs Stufen geteilt: Unit, Integration, System, E2E, UI-Performance und Backend-Performance. Sie werden oben umgeschaltet und jede führt ihre eigene Historie von Läufen.
Diese Teilung ist nicht kosmetisch. Ein fehlgeschlagener Unit-Test bedeutet etwas anderes als ein fehlgeschlagener E2E — und wenn du beides in einer Liste siehst, verlierst du genau die Information, für die die Stufen da sind.
Abdeckungskriterien — und wozu überhaupt
Wenn du Tests mit dem Satz „schreib Tests“ bestellst, bekommst du Tests. Die Frage ist, was sie prüfen — und darauf hat niemand eine Antwort, bis in der Produktion etwas umfällt.
Ein Abdeckungskriterium ist eine Regel, die sagt, wann es genug Tests sind. Es ist kein Prozentwert; es ist ein Satz, den man prüfen kann:
- Anweisungsabdeckung
- Jede Anweisung läuft mindestens einmal. Das Billigste und Schwächste — der Code lief, über seine Zweige sagt das nichts.
- Zweigabdeckung
- Jede Bedingung fällt einmal wahr und einmal falsch aus. Hier beginnen Tests Fehler zu finden.
- MC/DC
- Für jede Teilbedingung wird gezeigt, dass sie allein das Ergebnis ändert. Teuer, aber bei zusammengesetzten Bedingungen der einzige Weg, herauszufinden, dass eine davon überflüssig ist.
- Pair-wise
- Jedes Wertepaar aus verschiedenen Charakteristiken trifft sich in mindestens einem Test. Ein Bruchteil der Kombinationen, die meisten Fehler.
In der App wählst du das Kriterium beim Beauftragen der Tests und siehst dabei, wie anspruchsvoll es ist — bevor der Agent zu arbeiten beginnt. Das ist der Unterschied zu „schreib Tests“: du weißt, was du bekommst, und der Agent weiß, wann er aufhören soll.
Lass dir die Übersicht der Kriterien für dein Projekt vom Agenten erstellen. Er ergänzt bei jedem, wie anspruchsvoll es genau hier ist — bei einem Parser ist es etwas anderes als bei einem Formular.
Warum es ein Vorteil ist, das am Handy zu haben
- Ergebnisse liest man auch ohne Verbindung. Die Läufe sind heruntergeladen, du kannst also im Flugzeug darin wühlen.
- Von einem fehlgeschlagenen Fall führt ein Klick zu seiner Beschreibung in der Dokumentation und zu einem Screenshot aus dem Moment des Fehlschlags. Nicht zu hundert Zeilen Protokoll.
- Die Historie über die Läufe zeigt einen wackeligen Test — den, der einmal durchgeht und das nächste Mal nicht. Im Terminal erinnerst du dich an ihn, hier sieht man ihn.
- Gemessene Werte in Performance-Tests haben einen Verlauf über die Läufe. Eine Zahl sagt über eine Messung nichts, die Richtung schon.
- Weitere Tests zu beauftragen sind ein paar Tipper, kein Prompt. Man wählt Stufe und Kriterium, den Rest macht der Agent.
Woher die Ergebnisse kommen
Die App liest JUnit XML, also das Format, das fast jedes Testwerkzeug ausspucken kann. Der Agent schreibt es ins Projekt und das Handy lädt es mit dem Spiegel herunter — kein Dienst dazwischen, kein Upload irgendwohin.
Die Form, in der die Ergebnisse geschrieben werden, gibt ein Anwendungsskill vor. Skills werden über den Reiter Projekt, Abschnitt Anwendungsskills, ins Projekt gelegt; ohne sie siehst du nur, was im Projekt schon ist.
Woanders hängengeblieben als hier beschrieben? Schreib an support@coden-app.com.