Come generare file di test in una pipeline CI

Una fixture binaria in un repository resta per sempre nella sua cronologia, non si può rivedere in un diff e diventa impossibile quando il file è grande. Genera invece i file dentro la pipeline a partire da una ricetta. La ricetta è testo, i byte escono uguali ogni volta e un ultimo passo dimostra che nulla si è mosso.

La risposta breve

Installa tfg, esegui tfg generate fixtures.yaml --out ./fixtures prima dei test e tfg verify ./fixtures/manifest.json dopo. Entrambi i passi fanno fallire la build da soli, con un codice di uscita che dice perché.

Perché non committarli

Perché una fixture non deve stare nel repository

Resta nella cronologia. Cancellare un binario in seguito non rende più piccolo un clone, perché ogni sua versione è ancora lì.
Un diff non mostra cosa è cambiato. Chi rivede vede che un PDF è diverso e nient'altro. Una ricetta cambia di una riga.
I file grandi non ci stanno. GitHub rifiuta un push che contiene un file sopra i 100 MB, quindi un test di un limite di upload di 500 MB non ha nulla da committare.

Quello da committare è la ricetta. La stessa ricetta con lo stesso seme scrive gli stessi byte su ogni macchina, quindi il file generato nella pipeline è il file che avevi sul portatile.

La ricetta

Una ricetta che vive accanto ai test

Questa scrive venticinque fatture che devono essere accettate e due immagini oltre un limite che devono essere rifiutate, e il manifest registra entrambe le aspettative:

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 la controlla senza scrivere nulla e nomina tutti i problemi in una volta.

GitHub Actions

Un workflow che installa lo strumento e costruisce le fixture

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

La riga della somma di controllo confronta l'archivio con verify-SHA256SUMS.txt della stessa versione. La versione è fissata, quindi una nuova versione non cambia mai una build che non hai toccato.

GitLab CI

Lo stesso come job GitLab

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

Quando diventa rosso

Cosa fa fallire un passo, e perché

Ogni conclusione ha il suo codice di uscita, quindi il passo fallisce da solo e il log dice quale. Quelli che incontra una pipeline:

3 - la ricetta non è valida. Non è stato scritto nulla e ogni problema è nominato
4 - il formato non può fare ciò che è stato chiesto, per esempio una dimensione sotto il suo minimo
6 - non c'è abbastanza spazio su disco
7 - tfg verify ha trovato un file che non corrisponde al suo manifest
8 - l'esecuzione è finita, ma non tutto è stato prodotto

Un'esecuzione fallita non stampa nulla sullo standard output, così un parser di log non scambia mai un errore per dati. La tabella completa è nella pagina della documentazione.

PowerShell

Uno script PowerShell richiede una riga in più

PowerShell non porta fuori da un file .ps1 il codice di uscita di un programma. Eseguine uno con -File e lo script risponde 0 anche quando lo strumento al suo interno ha rifiutato il lavoro, così una build che dovrebbe essere rossa diventa verde. L'ultima riga è tutta la correzione:

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

È così che si comporta PowerShell, non qualcosa di questo strumento. cmd, bash e zsh non richiedono nulla di più.

Più job

Condividere le fixture tra i job

Di solito non serve caricarle. Poiché la stessa ricetta scrive gli stessi byte, ogni job può eseguire il proprio tfg generate, che è più rapido di un upload e di un download. Quando un job deve ricevere file da un altro, esegui tfg verify sul manifest dopo il trasferimento, e ti dice se ciò che è arrivato è ciò che è stato scritto.

Avanti

Dove andare da qui

File di test corrotti aggiunge alla stessa ricetta file rotti di proposito.
I casi d'uso mostrano cos'altro può controllare un'esecuzione in una pipeline.
La documentazione riporta ogni comando, ogni chiave della ricetta e ogni codice di uscita.