CLI-Referenz

Alle Befehle, Optionen und Umgebungsvariablen, jeweils mit ihrer Funktion, ihrem Standardwert und einem Beispiel. Mit td --help erhalten Sie die Kurzfassung.

td affected [options]              Print the projects and tests a change affects
td test [options] [-- <args>]      Run only the tests a change affects
td record [options]                Run all tests with coverage and store the map
td license status [options]        Check the license and show what it covers
td license install <license|file>  Store a license in ~/.testdetta/license

Optionen für jede Analyse

Diese funktionieren mit affected, test und record.

--base <ref>

Die Git-Ref, mit der verglichen wird. TestDetta vergleicht Ihr Arbeitsverzeichnis mit der Merge-Base von HEAD und dieser Ref, sodass Commits, die nach Ihrer Abzweigung auf dem Basis-Branch gelandet sind, nicht als Ihre Änderungen zählen. Standard: origin/main.

td test --base origin/develop
td affected --base HEAD~3      # the last three commits and anything uncommitted

--repo <path>

Ein beliebiger Pfad innerhalb des zu analysierenden Repositorys. Standard: das aktuelle Verzeichnis.

td affected --repo ../shop

-v, --verbose und --log-level <level>

Logs gehen nach stderr, sodass stdout maschinenlesbar bleibt. -v aktiviert Debug-Logs, die jede Entscheidung erklären: warum ein Projekt betroffen ist, welchen Member eine Testklasse ausgeführt hat, welchem Namen eine Verfolgung gefolgt ist. --log-level wählt eine der Stufen trace, debug, information, warning (Standard), error oder none; trace ergänzt die unverarbeitete Git-Ausgabe.

td affected -v 2> testdetta-debug.log
td test --log-level information

--max-map-age <n>

Verwendet eine Coverage-Map, die bis zu n First-Parent-Commits vor der Merge-Base aufgezeichnet wurde, wenn es an der Merge-Base selbst keine gibt. Die Änderungen dazwischen werden überbrückt: Klassen, die einen seit der Map geänderten Member ausgeführt haben, der Ihre Änderung erreichen kann, werden ebenfalls ausgewählt. 0 verwendet nur eine an der Merge-Base aufgezeichnete Map. Standard: 50. Siehe Wie es entscheidet.

td test --max-map-age 20

--drift-fallback <all|name>

Legt fest, was geschieht, wenn die Änderungen seit einer älteren Map etwas enthalten, das sich nicht durch Member beschreiben lässt: eine Build-Datei, Konfiguration, ein globales Using. all (Standard) führt die betroffenen Testprojekte vollständig aus; name entscheidet sie anhand von Namen, was schneller ist, aber blind für Aufrufe, die über Konfiguration oder Reflection verbunden sind.

td test --drift-fallback name

--maps-dir <dir>

Bewahrt Coverage-Maps außerhalb des Repositorys auf, ein Ordner pro Commit. record speichert nach <dir>/<commit>/; affected und test stellen die neueste innerhalb von --max-map-age wieder her. Verwenden Sie die Option auf anderen CI-Systemen als GitHub Actions, mit einem gemeinsamen Laufwerk oder einem synchronisierten Objektspeicher. Standard: Die Maps liegen in .testdetta/coverage im Repository.

td record --maps-dir /srv/testdetta-maps/shop
td test --base origin/main --maps-dir /srv/testdetta-maps/shop

td affected

Gibt aus, was eine Änderung betrifft und warum, ohne etwas zu bauen oder auszuführen.

--format <text|json|paths|commands>

FormatAusgabeVerwendung
text (Standard)Betroffene Projekte mit dem Grund, danach der TestplanZum Lesen
jsonJedes Projekt und jede Testklasse mit Entscheidung, Belegen und ZeitschätzungSkripte, Dashboards
pathsEine betroffene Test-.csproj pro ZeileAls Eingabe für ein anderes Tool
commandsEin dotnet test-Befehl pro Testprojekt, mit seinem FilterUm die Tests auf eigene Weise auszuführen
td affected --format json > plan.json
td affected --format paths | xargs -n1 dotnet build

--tests-only

Listet nur die betroffenen Testprojekte auf, nicht die Produktionsprojekte auf dem Weg dorthin.

td test

Baut und führt nur die betroffenen Tests aus: einen Filter pro Testprojekt, wenn nur einige Klassen betroffen sind, das ganze Projekt, wenn alle betroffen sind oder sich eine Änderung nicht eingrenzen lässt, und nichts, wenn keine betroffen ist. Exitcode 3, wenn ein Test fehlschlägt.

--dry-run

Gibt die dotnet test-Befehle aus, statt sie auszuführen. Ein Projekt, dessen global.json in einem Unterordner liegt, wird als (cd src && dotnet test ...) ausgegeben.

--summary-file <path>

Hängt eine Markdown-Zusammenfassung an: das Ergebnis jedes Projekts, welche Klassen liefen und warum, welche übersprungen wurden und die eingesparte aufgezeichnete Testzeit. Verweisen Sie in GitHub Actions auf $GITHUB_STEP_SUMMARY; die Action erledigt das für Sie. Siehe ein Beispiel.

td test --summary-file "$GITHUB_STEP_SUMMARY"

-- <dotnet test arguments>

Alles nach -- wird an jeden dotnet test-Aufruf übergeben.

td test -- -c Release --logger trx
td test -- --no-restore

td record

Führt alle Tests mit Coverage aus und schreibt eine Map pro Testprojekt nach .testdetta/coverage (oder --maps-dir). Führen Sie den Befehl auf Ihrem Standard-Branch aus; er ist zugleich der vollständige Testlauf dieses Branches. Exitcode 3, wenn Tests fehlschlagen; die Maps werden trotzdem geschrieben, und die fehlschlagenden Klassen werden später immer ausgewählt.

-c, --configuration <name>

Build-Konfiguration. Standard: Debug.

-f, --framework <tfm>

Das Ziel-Framework, das in einem Testprojekt mit mehreren Ziel-Frameworks aufgezeichnet wird. Standard: das erste Ziel-Framework des Projekts.

td record -f net10.0

--project <path>

Zeichnet nur dieses Testprojekt auf, relativ zum Stammverzeichnis des Repositorys; für mehrere Projekte wiederholen Sie die Option. Lassen Sie Projekte weg, die in der CI nicht laufen können, etwa Integrationstests, die eine Datenbank benötigen; sie werden dann anhand von Namen entschieden.

td record --project tests/Shop.Tests/Shop.Tests.csproj --project tests/Api.Tests/Api.Tests.csproj

--parallel <n>

Verteilt die Testklassen jedes Projekts auf n Testprozesse, um schneller aufzuzeichnen. Jeder Prozess führt seine Tests weiterhin einzeln nacheinander aus. Ihre Testsuite muss mehrere gleichzeitige Testprozesse vertragen (keine festen Ports oder gemeinsam genutzten Dateien). Standard: 1.

--no-build

Zeichnet die Ausgabe eines früheren Builds mit derselben Konfiguration auf, statt erneut zu bauen.

dotnet build -c Release
td record -c Release --no-build

td license

td license status prüft die Lizenz so, wie td test es tun würde, und gibt aus, was sie abdeckt: Lizenznehmer, Seats, aktive Committer der letzten 30 Tage, die Bot-Liste, Scopes und das Enddatum. Es sendet keine personenbezogenen Daten irgendwohin. td license install <license|file> speichert eine Lizenz in ~/.testdetta/license, für Rechner, auf denen kein CI-Secret sie aufnehmen kann. Siehe Lizenz.

Umgebungsvariablen

VariableFunktion
TESTDETTA_LICENSEDer Lizenzstring, aus einem CI-Secret.
TESTDETTA_LICENSE_FILEEine Datei, die den Lizenzstring enthält.
TESTDETTA_LICENSE_REFRESH=offSchaltet die tägliche Lizenzaktualisierung ab, für Netzwerke, die den Lizenzdienst nicht erreichen können.
TESTDETTA_LICENSE_SCOPEDas Repository, das die Lizenz abdecken muss, wenn der Remote origin es nicht benennt (zum Beispiel bei einem lokalen Mirror).
HTTPS_PROXYProxy für die Lizenzaktualisierung.

Exitcodes

CodeBedeutung
0Erfolg, auch wenn keine Tests nötig sind.
1Die Analyse ist fehlgeschlagen: Git, das Dateisystem oder eine Projektdatei.
2Ungültige Befehlszeile.
3Tests sind fehlgeschlagen (test und record).