TestDetta

Im eigenen Repository prüfen

Unsere Evaluierung läuft auf Open-Source-Bibliotheken. Ihr Code hat eigene Muster, also prüfen Sie TestDetta daran, bevor Sie es entscheiden lassen, was läuft. Das dauert ein paar Wochen mit normalen Pull Requests und ändert nichts für Ihr Team.

Die Idee

Lassen Sie weiterhin die vollständige Testsuite als Gate laufen. Fragen Sie TestDetta daneben, was es ausgewählt hätte. Jede Testklasse, die im vollständigen Lauf fehlschlägt, muss in dieser Auswahl enthalten sein. Fehlt eine, ist das ein übersehener Test, und davon wollen wir erfahren.

Schritte

  1. Maps auf dem Standard-Branch aufzeichnen. Mit GitHub Actions fügen Sie den Schritt record aus dem Workflow hinzu; anderswo führen Sie td record bei jedem Commit auf dem Standard-Branch aus und bewahren die Maps auf (Andere CI-Systeme).
  2. Bei jedem Pull Request die Auswahl festhalten. Ohne Ihren Testschritt zu ändern: 
    td affected --format json > selection.json
  3. Die vollständige Testsuite wie heute ausführen, mit einem TRX-Bericht, damit sich Fehlschläge auslesen lassen: 
    dotnet test --logger trx --results-directory TestResults
  4. Vergleichen. Für jeden fehlgeschlagenen Test muss seine Klasse ausgewählt sein. Eine Klasse ist ausgewählt, wenn der mode ihres Projekts All ist oder wenn ihr Projekt Filtered ist und die Klasse in classes steht: 
    jq -r '.tests[] | select(.mode == "All") | .project' selection.json      # projects that run completely
jq -r '.tests[] | select(.mode == "Filtered") | .classes[]' selection.json  # classes that run
  5. Beide Dateien aufbewahren, wenn in einem Lauf eine fehlgeschlagene Klasse nicht ausgewählt war, und sie zusammen mit dem -v-Log von td affected an support@testdetta.com senden.

Nur fehlschlagende Tests können einen übersehenen Test zeigen, und ein paar Wochen bringen vielleicht wenige Fehlschläge. Sie können welche hinzufügen: Brechen Sie auf einem Wegwerf-Branch absichtlich eine Methode (lassen Sie sie einen falschen Wert zurückgeben) und prüfen Sie, ob der Test, der das bemerkt, ausgewählt wird. Mergen Sie diesen Branch nicht.

Wenn Sie sicher sind

Ersetzen Sie den vollständigen Testschritt durch td test oder den Modus test der Action. Zeichnen Sie auf dem Standard-Branch weiter auf: Dort laufen alle Tests, sodass alles, was eine Auswahl je verbergen könnte, trotzdem vor dem Release auffällt.

Wie wir es testen

Dieselbe Prüfung läuft im großen Maßstab auf 41 Open-Source-Repositorys: Member werden einzeln geändert, und jede Testklasse, die fehlschlägt, muss ausgewählt worden sein. Von 2.941 Änderungen, die einen Test brachen, wurden 3 übersehen, und jede wurde mit einem Test behoben, der ohne die Korrektur fehlschlägt. Der Korpus in Zahlen.