So erzeugen Sie Testdateien in einer CI-Pipeline

Ein binäres Fixture in einem Repository bleibt für immer in dessen Verlauf, lässt sich in einem Diff nicht prüfen und geht bei großen Dateien gar nicht mehr. Erzeugen Sie die Dateien stattdessen in der Pipeline aus einem Rezept. Das Rezept ist Text, die Bytes sind jedes Mal dieselben, und ein letzter Schritt beweist, dass sich nichts verändert hat.

Die kurze Antwort

Installieren Sie tfg, führen Sie vor den Tests tfg generate fixtures.yaml --out ./fixtures aus und danach tfg verify ./fixtures/manifest.json. Beide Schritte lassen den Build von selbst scheitern, mit einem Exit-Code, der sagt, warum.

Warum nicht einchecken

Warum ein Fixture nicht im Repository liegen sollte

Es bleibt im Verlauf. Eine Binärdatei später zu löschen macht einen Klon nicht kleiner, denn jede ihrer Versionen ist weiterhin da.
Ein Diff zeigt nicht, was sich geändert hat. Der Reviewer sieht, dass eine PDF anders ist, und sonst nichts. Ein Rezept ändert sich um eine Zeile.
Große Dateien passen nicht. GitHub lehnt einen Push mit einer Datei über 100 MB ab, also gibt es für den Test eines Upload-Limits von 500 MB nichts einzuchecken.

Einzuchecken ist das Rezept. Dasselbe Rezept mit demselben Seed schreibt auf jeder Maschine dieselben Bytes, die in der Pipeline erzeugte Datei ist also die Datei, die Sie auf dem Laptop hatten.

Das Rezept

Ein Rezept, das neben den Tests liegt

Dieses schreibt fünfundzwanzig Rechnungen, die angenommen werden sollen, und zwei Bilder über einem Limit, die abgewiesen werden sollen, und das Manifest hält beide Erwartungen fest:

version: 1
seed: 7741

targets:
  - id: invoices
    format: pdf
    count: 25
    size: 300kb
    expected: accept

  - id: over_the_limit
    format: png
    count: 2
    size: 12mb
    expected:
      outcome: reject
      reason: size_limit

tfg validate fixtures.yaml prüft es, ohne etwas zu schreiben, und nennt jedes Problem auf einmal.

GitHub Actions

Ein Workflow, der das Tool installiert und die Fixtures erzeugt

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      TFG_VERSION: "0.4.0"
    steps:
      - uses: actions/checkout@v4

      - name: install tfg
        run: |
          base=https://github.com/donislawdev/TestingFilesGenerator/releases/download/v$TFG_VERSION
          curl -fsSLO "$base/tfg_${TFG_VERSION}_linux_amd64.tar.gz"
          curl -fsSLO "$base/verify-SHA256SUMS.txt"
          sha256sum --check --ignore-missing verify-SHA256SUMS.txt
          tar -xzf "tfg_${TFG_VERSION}_linux_amd64.tar.gz" ./tfg
          sudo mv tfg /usr/local/bin/

      - name: build the fixtures
        run: tfg generate fixtures.yaml --out ./fixtures

      - name: run the tests
        run: pytest tests/

      - name: nothing moved
        run: tfg verify ./fixtures/manifest.json

Die Prüfsummenzeile vergleicht das Archiv mit verify-SHA256SUMS.txt aus demselben Release. Die Version ist festgelegt, ein neues Release ändert also nie einen Build, den Sie nicht angefasst haben.

GitLab CI

Dasselbe als GitLab-Job

fixtures:
  image: ubuntu:24.04
  variables:
    TFG_VERSION: "0.4.0"
  script:
    - apt-get update -qq && apt-get install -y -qq curl ca-certificates
    - base=https://github.com/donislawdev/TestingFilesGenerator/releases/download/v$TFG_VERSION
    - curl -fsSLO "$base/tfg_${TFG_VERSION}_linux_amd64.tar.gz"
    - curl -fsSLO "$base/verify-SHA256SUMS.txt"
    - sha256sum --check --ignore-missing verify-SHA256SUMS.txt
    - tar -xzf "tfg_${TFG_VERSION}_linux_amd64.tar.gz" ./tfg
    - ./tfg generate fixtures.yaml --out ./fixtures
    - pytest tests/
    - ./tfg verify ./fixtures/manifest.json

Wenn es rot wird

Was einen Schritt scheitern lässt, und warum

Jedes Ende hat seinen eigenen Exit-Code, der Schritt scheitert also von selbst, und das Log sagt, welcher es war. Die, denen eine Pipeline begegnet:

3 - das Rezept ist ungültig. Es wurde nichts geschrieben, und jedes Problem wird genannt
4 - das Format kann nicht, was verlangt wurde, zum Beispiel eine Größe unter seinem Minimum
6 - es ist nicht genug Speicherplatz da
7 - tfg verify hat eine Datei gefunden, die nicht zu ihrem Manifest passt
8 - der Lauf ist fertig, aber nicht alles wurde erzeugt

Ein fehlgeschlagener Lauf gibt nichts auf der Standardausgabe aus, sodass ein Log-Parser nie einen Fehler für Daten hält. Die ganze Tabelle steht auf der Dokumentationsseite.

PowerShell

Ein PowerShell-Skript braucht eine Zeile mehr

PowerShell trägt den Exit-Code eines Programms nicht aus einer .ps1-Datei heraus. Starten Sie eine mit -File, und das Skript antwortet 0, auch wenn das Tool darin die Arbeit verweigert hat, sodass ein Build, der rot sein sollte, grün wird. Die letzte Zeile ist die ganze Lösung:

tfg generate fixtures.yaml --out ./fixtures
exit $LASTEXITCODE

So verhält sich PowerShell, es liegt nicht an diesem Tool. cmd, bash und zsh brauchen nichts zusätzlich.

Mehrere Jobs

Fixtures zwischen Jobs teilen

Hochladen ist meist nicht nötig. Weil dasselbe Rezept dieselben Bytes schreibt, kann jeder Job sein eigenes tfg generate ausführen, und das geht schneller als Hoch- und Herunterladen. Muss ein Job Dateien von einem anderen erhalten, führen Sie nach der Übertragung tfg verify auf dem Manifest aus, und es sagt, ob das Angekommene dem Geschriebenen entspricht.

Weiter

Wohin es von hier geht

Beschädigte Testdateien fügen demselben Rezept absichtlich kaputte Dateien hinzu.
Die Anwendungsfälle zeigen, was ein Lauf in einer Pipeline sonst noch prüfen kann.
Die Dokumentation kennt jeden Befehl, jeden Rezept-Schlüssel und jeden Exit-Code.