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>
| Format | Ausgabe | Verwendung |
|---|---|---|
text (Standard) | Betroffene Projekte mit dem Grund, danach der Testplan | Zum Lesen |
json | Jedes Projekt und jede Testklasse mit Entscheidung, Belegen und Zeitschätzung | Skripte, Dashboards |
paths | Eine betroffene Test-.csproj pro Zeile | Als Eingabe für ein anderes Tool |
commands | Ein dotnet test-Befehl pro Testprojekt, mit seinem Filter | Um 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
| Variable | Funktion |
|---|---|
TESTDETTA_LICENSE | Der Lizenzstring, aus einem CI-Secret. |
TESTDETTA_LICENSE_FILE | Eine Datei, die den Lizenzstring enthält. |
TESTDETTA_LICENSE_REFRESH=off | Schaltet die tägliche Lizenzaktualisierung ab, für Netzwerke, die den Lizenzdienst nicht erreichen können. |
TESTDETTA_LICENSE_SCOPE | Das Repository, das die Lizenz abdecken muss, wenn der Remote origin es nicht benennt (zum Beispiel bei einem lokalen Mirror). |
HTTPS_PROXY | Proxy für die Lizenzaktualisierung. |
Exitcodes
| Code | Bedeutung |
|---|---|
0 | Erfolg, auch wenn keine Tests nötig sind. |
1 | Die Analyse ist fehlgeschlagen: Git, das Dateisystem oder eine Projektdatei. |
2 | Ungültige Befehlszeile. |
3 | Tests sind fehlgeschlagen (test und record). |