Erste Schritte

TestDetta vergleicht Ihren Branch mit seiner Basis, ermittelt, welche Testprojekte und welche Testklassen die Änderung bemerken können, und führt nur diese aus. Ist es sich nicht sicher, führt es mehr aus, nie weniger.

Voraussetzungen

Das .NET 10 SDK, um TestDetta selbst auszuführen. Ihre Tests verwenden weiterhin das SDK und den Test Runner, die Ihr Repository bereits nutzt.
Vollständige Git-Historie. TestDetta vergleicht mit der Merge-Base Ihres Branches und durchläuft die Historie, um Coverage-Maps zu finden. Shallow Clones können beides nicht.
Der Ziel-Branch ist abgerufen, sodass eine Ref wie origin/main existiert.
Ein Test Runner, wie dotnet test ihn sieht. Beide Test Runner werden unterstützt; der Test Runner wird aus global.json gelesen ("test": { "runner": "Microsoft.Testing.Platform" }), Standard ist VSTest.

Schnellstart

GitHub Actions

Die GitHub Action baut TestDetta für Sie; Sie müssen nichts installieren. Fügen Sie Ihrem Workflow zwei Schritte hinzu: Einer zeichnet bei Pushes auf Ihren Standard-Branch eine Coverage-Map auf, der andere führt in Pull Requests nur die betroffenen Tests aus.

- if: github.event_name == 'push'
  uses: <owner>/testdetta@<sha>
  with:
    mode: record

- if: github.event_name == 'pull_request'
  uses: <owner>/testdetta@<sha>
  with:
    mode: test

Den vollständigen Workflow, die benötigten Berechtigungen und alle Eingaben finden Sie unter GitHub Actions.

Andere CI-Systeme

GitLab CI, Jenkins, Azure DevOps, Bitbucket und On-Premises-Umgebungen führen dieselben zwei Befehle aus, mit einem Ordner von Coverage-Maps pro Commit (--maps-dir), der auf einem gemeinsamen Laufwerk oder in einem Objektspeicher liegt. Installieren Sie TestDetta als .NET-Tool:

dotnet tool install --global <package>

Der Paketname wird zum Launch festgelegt. Bis dahin bauen Sie das Tool aus dem Quellcode mit dotnet build src/TestDetta.Cli -c Release -o testdetta-bin und rufen überall dort, wo td steht, dotnet testdetta-bin/TestDetta.Cli.dll auf.

Pipelines für jedes System finden Sie unter Andere CI-Systeme.

Erste Befehle

Führen Sie diese an beliebiger Stelle innerhalb Ihres Repositorys aus. --base ist standardmäßig origin/main.

# What does my branch affect, and why?
td affected --base origin/main

# Run only the affected tests (add --dry-run to print the dotnet test commands)
td test --base origin/main

# Run every test with coverage and write one map per test project to .testdetta/coverage
td record

Ohne Coverage-Map funktioniert td test trotzdem: Es entscheidet nur anhand von Namen, was sicher ist, aber mehr auswählt. Sobald td record an der Basis Ihres Branches gelaufen ist, wird die Auswahl präzise.

Nehmen Sie .testdetta/ in Ihre .gitignore auf. Der Ordner enthält Coverage-Maps und Caches, nie etwas, das committet werden sollte.

Befehle

Befehl	Funktion
`td affected [--format text\|json\|paths\|commands]`	Gibt aus, was eine Änderung betrifft und warum. `--tests-only` listet nur die betroffenen Testprojekte auf.
`td test [--dry-run] [--summary-file <path>] [-- <dotnet test args>]`	Führt nur die betroffenen Tests aus. `--summary-file` hängt eine Markdown-Zusammenfassung an, zum Beispiel an `$GITHUB_STEP_SUMMARY`. Argumente nach `--` gehen an jeden `dotnet test`-Aufruf, zum Beispiel `-- -c Release`.
`td record [--project <csproj>]... [-c <configuration>] [-f <tfm>] [--parallel <n>] [--no-build]`	Führt alle Tests mit Coverage aus und schreibt eine Map pro Testprojekt nach `.testdetta/coverage`. `--parallel` verteilt die Testklassen jedes Projekts auf n Testprozesse; `--no-build` zeichnet die Ausgabe eines früheren Builds mit derselben Konfiguration auf.
`td license status`	Prüft die Lizenz und zeigt, was sie abdeckt.
`td license install <license\|file>`	Speichert eine Lizenz in `~/.testdetta/license`, für Rechner, auf denen kein CI-Secret sie aufnehmen kann.

Gemeinsame Optionen

Option	Bedeutung
`--base <ref>`	Git-Ref, mit der verglichen wird. Standard: `origin/main`.
`--repo <path>`	Ein beliebiger Pfad innerhalb des Repositorys. Standard: das aktuelle Verzeichnis.
`--max-map-age <n>`	Verwendet Coverage-Maps, die bis zu n Commits vor der Merge-Base aufgezeichnet wurden, und überbrückt die Änderungen dazwischen. Standard: 50; 0 verwendet nur exakte Maps. Siehe Wie es entscheidet.
`--maps-dir <dir>`	Coverage-Maps außerhalb des Repositorys, ein Ordner pro Commit: `record` speichert dort, `affected` und `test` stellen die neueste innerhalb von `--max-map-age` wieder her. Für andere CI-Systeme als GitHub Actions.
`--drift-fallback <all\|name>`	Wenn die Änderungen seit einer älteren Map eine Build-Datei, Konfiguration oder ein globales Using enthalten: die betroffenen Testprojekte vollständig ausführen (`all`, der Standard) oder anhand von Namen entscheiden (`name`).
`-v`, `--verbose`	Schreibt Debug-Logs nach stderr: jede Entscheidung, die ein Benutzer hinterfragen könnte, mit ihrem Grund.
`--log-level <level>`	`trace`, `debug`, `information`, `warning` (Standard), `error` oder `none`.

Logs gehen nach stderr; stdout enthält die Ausgabe des Befehls und bleibt maschinenlesbar.

Exitcodes

Code	Bedeutung
`0`	Erfolg.
`1`	Die Analyse ist fehlgeschlagen.
`2`	Ungültige Befehlszeile.
`3`	Tests sind fehlgeschlagen.