Fehlerbehebung

Jeder Eintrag geht von dem aus, was Sie sehen. Bei allen schreibt -v jede Entscheidung samt Grund nach stderr; dieses Log beantwortet die meisten Fragen, und genau das sollten Sie uns schicken.

td affected --base origin/main -v

Das ganze Testprojekt lief

Suchen Sie das Projekt in der Ausgabe: Der Grund steht daneben. Die üblichen Ursachen sind eine build-weite Datei, eine Nicht-C#-Datei im Projekt, ein global using oder ein per Reflection gefundener Typ. Was alle Tests auslöst listet sie alle auf. Im -v-Log nennt eine Zeile wie affects whole project: True die Datei.

Es wurde keine Coverage-Map verwendet

Ohne Map verfolgt die Auswahl Namen, was breiter ist. Das Log sagt, warum es keine gab:

No coverage maps within 50 commits before the merge base: Auf dem Standard-Branch wurde in letzter Zeit nichts aufgezeichnet. Zeichnen Sie dort bei jedem Push eine Map auf; der Modus record der Action erledigt das.
Ignoring the coverage map of … which is not an ancestor of the base: Die Map stammt aus einem anderen Branch oder aus der Zeit vor einem Force-Push oder einem langlebigen Branch. Zeichnen Sie auf dem Standard-Branch erneut auf oder erhöhen Sie --max-map-age.
--maps-dir … does not exist: Der Ordner mit den Maps wurde vor dem Lauf nicht wiederhergestellt.
Unter GitHub Actions benötigt der Job die Berechtigung actions: read, um die Cache-Einträge mit den Maps aufzulisten.

Der Basis-Commit wird nicht gefunden

TestDetta vergleicht Ihren Branch mit der Merge-Base und braucht daher die Historie beider. Die Action bricht ab mit:

TestDetta compares with a base commit and needs the full history. Use actions/checkout with fetch-depth: 0.

Checken Sie mit fetch-depth: 0 aus. In anderen CI-Systemen schalten Sie Shallow Clones ab und rufen den Ziel-Branch mit einer expliziten Refspec ab, wie für jedes System unter Andere CI-Systeme gezeigt.

Weniger Tests übersprungen als erwartet

Die Map ist älter als die Merge-Base, und dazwischen hat sich eine Build- oder Konfigurationsdatei geändert: Die betroffenen Projekte laufen vollständig. --drift-fallback name grenzt sie stattdessen anhand von Namen ein.
Eine Testklasse wird ausgewählt, ohne die Änderung zu berühren. Die Namensverfolgung ist vorsichtig: Eine Klasse, die den geänderten Typ nennt, wird ausgewählt, auch wenn die Coverage sie ausgeschlossen hätte. Eine Logzeile wie is not in the coverage map of … Record the map again bedeutet, dass die Map für dieses Projekt veraltet ist.
Ein zentraler Helfer hat sich geändert. Code, den die meisten Tests ausführen, etwa eine gemeinsame Basisklasse oder ein Serializer, wählt die meisten Tests aus. Das ist korrekt.

Der Filter entsprach keinem Test

Wählt der Filter eines Projekts keinen Test aus, führt TestDetta das Projekt ohne Filter erneut aus und loggt The filter for … matched no test; running it unfiltered. Nichts wird übersehen, aber das ist ein Fehler auf unserer Seite: Bitte senden Sie uns das -v-Log.

Squash-Merges, Rebases und Force-Pushes

Maps werden für Commits auf dem Standard-Branch aufgezeichnet, und ein Pull Request findet die neueste an oder vor seiner Merge-Base. Ein Squash-Merge oder Rebase erzeugt neue Commits auf dem Standard-Branch; der nächste Push zeichnet eine Map für sie auf, und bis dahin verwenden Pull Requests die vorherige Map über die Drift-Bridge. Ein Force-Push auf einen Pull-Request-Branch ändert nichts: Die Merge-Base wird neu berechnet.

Pull Requests aus Forks

CI-Systeme geben Secrets nicht an Pull Requests aus Forks weiter. Öffentliche Repositorys benötigen keine Lizenz, für sie ändert sich also nichts. Bei einem privaten Repository führt ein Lauf ohne Lizenz alle Tests aus, wie ohne TestDetta.

Fragen

Ist die Code-Coverage eines ausgewählten Laufs vollständig?

Nein. Ein Lauf, der Tests überspringt, erzeugt unvollständige Coverage. Veröffentlichen Sie die Coverage der vollständigen Läufe auf dem Standard-Branch; die Aufzeichnung führt dort alle Tests aus.

Lassen sich Tests wiederholen?

Ja, mit der eigenen Retry-Option Ihres Frameworks: Alles nach -- geht unverändert an dotnet test.

Lassen sich die ausgewählten Tests auf parallele Jobs verteilen?

td affected --format commands gibt einen dotnet test-Befehl pro Testprojekt samt Filter aus. Verteilen Sie die Zeilen auf Ihre Jobs.