GitHub Actions

Zeichnen Sie für jeden Commit auf dem Standard-Branch eine Map auf, und lassen Sie Pull Requests nur die Tests ausführen, die ihre Änderungen betreffen. Die Action baut TestDetta selbst und legt die Maps im Actions-Cache ab.

Workflow

on:
  push:
    branches: [main]
  pull_request:

permissions:
  contents: read
  actions: read # lets pull requests find the newest coverage map in the Actions cache

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7 # pin to a commit SHA
        with:
          fetch-depth: 0 # TestDetta compares with the merge base
          persist-credentials: false

      - uses: actions/setup-dotnet@v6 # pin to a commit SHA
        with:
          global-json-file: global.json

      # Also the full test run of main. Leave out projects that cannot run here, such as
      # integration tests that need a database; they are then decided by name on pull requests.
      - if: github.event_name == 'push'
        uses: <owner>/testdetta@<sha>
        with:
          mode: record
          projects: |
            tests/Shop.Tests/Shop.Tests.csproj

      - if: github.event_name == 'pull_request'
        uses: <owner>/testdetta@<sha>
        with:
          mode: test
          dotnet-test-args: --logger trx
          license: ${{ secrets.TESTDETTA_LICENSE }}

Die vollständige Historie ist erforderlich. Bei einem Shallow Clone bricht die Action mit einem Fehler ab. Checken Sie mit fetch-depth: 0 aus.

Wie die Maps zu den Pull Requests gelangen

Der Record-Modus speichert die Maps im Actions-Cache unter testdetta-coverage-<commit>. Pull Requests können die Caches ihres Basis-Branches lesen.
Ein Pull Request verwendet die Map seiner Merge-Base oder die neueste, die bis zu max-map-age First-Parent-Commits davor aufgezeichnet wurde.
Um eine solche nicht exakt passende Map zu finden, werden die Caches des Repositorys aufgelistet, was actions: read erfordert. Ohne diese Berechtigung wird nur eine Map an der Merge-Base gefunden, und der Schritt weist in einem Hinweis darauf hin.
Ganz ohne Map funktioniert mode: test trotzdem und entscheidet nur anhand von Namen.

Wenn bei der Aufzeichnung Tests fehlschlagen, wird die Map trotzdem gespeichert, bevor der Job fehlschlägt, sodass Pull Requests weiterhin eine Map zur Verfügung haben.

Berechtigungen

Berechtigung	Wozu
`contents: read`	Das Repository auschecken.
`actions: read`	Die Actions-Caches auflisten, um die neueste Map innerhalb von `max-map-age` zu finden.

Mit persist-credentials: false kann ein privates Repository später im Job nicht erneut abgerufen werden; fetch-depth: 0 holt bereits alle Branches, sodass der Basis-Branch vorhanden ist.

Eingaben

Eingabe	Standard	Beschreibung
`mode`		`test` in Pull Requests (betroffene Tests ausführen), `record` auf dem Standard-Branch (Coverage-Maps aufzeichnen). Erforderlich.
`base`	der Basis-Branch des PR	Branch, mit dem im Test-Modus verglichen wird. Außerhalb von Pull Requests müssen Sie ihn setzen.
`configuration`	`Debug`	Build-Konfiguration zum Bauen und Ausführen der Tests.
`projects`	alle Testprojekte	Record-Modus: `.csproj`-Pfade, einer pro Zeile.
`parallel`	`1`	Record-Modus: Testhost-Prozesse pro Testprojekt; jeder führt seine Tests weiterhin einzeln nacheinander aus. Die Testsuite muss mehrere gleichzeitige Testprozesse vertragen.
`no-build`	`false`	Record-Modus: `true`, um den Build aufzuzeichnen, den ein früherer Schritt mit derselben `configuration` erstellt hat.
`dotnet-test-args`		Test-Modus: zusätzliche `dotnet test`-Argumente, durch Leerzeichen getrennt.
`max-map-age`	`50`	Test-Modus: Anzahl der Commits, die eine Map hinter der Merge-Base liegen darf; die Änderungen dazwischen werden überbrückt. `0` verwendet nur eine exakte Map.
`drift-fallback`	`all`	Test-Modus: Wenn die Änderungen seit einer älteren Map eine Build-Datei, Konfiguration oder ein globales Using enthalten, führt `all` die betroffenen Testprojekte vollständig aus; `name` entscheidet sie anhand von Namen (schneller, aber blind für Aufrufe über Konfiguration oder Reflection).
`github-token`	`github.token`	Test-Modus: listet die Actions-Caches auf, um die neueste Map zu finden (erfordert `actions: read`).
`license`		Test-Modus: der Lizenzstring, aus einem Repository- oder Organisations-Secret wie `TESTDETTA_LICENSE`. Öffentliche Repositorys benötigen keinen. Ohne gültige Lizenz laufen alle Tests; der Job schlägt deswegen nie fehl.
`working-directory`	`.`	Ein beliebiges Verzeichnis innerhalb des zu analysierenden Repositorys.
`setup-dotnet`	`true`	Installiert das .NET 10 SDK, auf dem TestDetta läuft. Setzen Sie den Wert auf `false`, wenn der Job es bereits hat.

Job Summary

Im Test-Modus schreibt TestDetta seine Auswahl in die Job Summary: die geänderten Dateien und die Basis, mit der verglichen wurde, jedes Testprojekt mit der Angabe, ob es gefiltert, vollständig oder gar nicht lief und warum, die Testergebnisse sowie den Lizenzstatus, wenn er relevant ist. Pfade, Klassennamen und Gründe aus dem Repository werden als Code geschrieben, sodass Dateinamen in einem Pull Request keine Links oder Erwähnungen in die Seite einschleusen können.

Nur einen Teil der Testsuite aufzeichnen

Die Aufzeichnung führt die gesamte Testsuite einmal mit Coverage aus, was auf dem Standard-Branch zugleich Ihr vollständiger Testlauf ist. Projekte, die auf dem Runner nicht laufen können, etwa Integrationstests, die eine Datenbank benötigen, lassen Sie mit projects weg. Pull Requests entscheiden diese Projekte dann anhand von Namen.

Wenn ein früherer Schritt die Solution bereits mit derselben Konfiguration gebaut hat, setzen Sie no-build: true. Für eine Testsuite, die mehrere gleichzeitige Testprozesse verträgt, verteilt parallel die Testklassen jedes Projekts auf entsprechend viele Prozesse.