Cum generezi fișiere de test într-un pipeline CI

De ce să nu le comiți

De ce un fixture nu trebuie să stea în repository

• Rămâne în istoric. Ștergerea ulterioară a unui binar nu face un clon mai mic, pentru că fiecare versiune a lui este încă acolo.
• Un diff nu arată ce s-a schimbat. Cel care revizuiește vede că un PDF este diferit și nimic altceva. O rețetă se schimbă cu o linie.
• Fișierele mari nu încap. GitHub refuză un push care conține un fișier de peste 100 MB, așa că un test al unei limite de încărcare de 500 MB nu are ce comite.

Ce trebuie comis este rețeta. Aceeași rețetă și același seed scriu aceiași octeți pe orice mașină, deci fișierul generat în pipeline este fișierul pe care l-ai avut pe laptop.

Rețeta

O rețetă care stă lângă teste

Aceasta scrie douăzeci și cinci de facturi care trebuie acceptate și două imagini peste o limită care trebuie respinse, iar manifestul notează ambele așteptări:

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 o verifică fără să scrie nimic și numește toate problemele deodată.

GitHub Actions

Un workflow care instalează instrumentul și construiește fixture-urile

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

Linia cu suma de control compară arhiva cu verify-SHA256SUMS.txt din aceeași versiune. Versiunea este fixată, așa că o versiune nouă nu schimbă niciodată un build pe care nu l-ai atins.

GitLab CI

Același lucru ca 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

Când se face roșu

Ce face un pas să eșueze, și de ce

Fiecare final are propriul cod de ieșire, deci pasul eșuează singur, iar jurnalul spune care a fost. Cele pe care le întâlnește un pipeline:

• 3 - rețeta nu este validă. Nu s-a scris nimic, iar fiecare problemă este numită
• 4 - formatul nu poate face ce s-a cerut, de exemplu o mărime sub minimul lui
• 6 - nu este destul spațiu pe disc
• 7 - tfg verify a găsit un fișier care nu se potrivește cu manifestul lui
• 8 - rularea s-a încheiat, dar nu s-a produs totul

O rulare eșuată nu afișează nimic la ieșirea standard, așa că un parser de jurnale nu ia niciodată o eroare drept date. Tabelul complet este pe pagina de documentație.

PowerShell

Un script PowerShell mai are nevoie de o linie

PowerShell nu scoate codul de ieșire al unui program dintr-un fișier .ps1. Rulează unul cu -File și scriptul răspunde 0 chiar și când instrumentul dinăuntru a refuzat lucrul, așa că un build care ar trebui să fie roșu devine verde. Ultima linie este toată soluția:

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

Așa se comportă PowerShell, nu este ceva legat de acest instrument. cmd, bash și zsh nu au nevoie de nimic în plus.

Mai multe joburi

Împărțirea fixture-urilor între joburi

De obicei nu e nevoie să le încarci. Fiindcă aceeași rețetă scrie aceiași octeți, fiecare job își poate rula propriul tfg generate, ceea ce e mai rapid decât o încărcare și o descărcare. Când un job trebuie să primească fișiere de la altul, rulează tfg verify pe manifest după transfer, și îți spune dacă ce a ajuns este ce s-a scris.

Mai departe

Unde să mergi de aici

• Fișiere de test corupte adaugă aceleiași rețete fișiere stricate intenționat.
• Cazurile de utilizare arată ce altceva poate verifica o rulare într-un pipeline.
• Documentația cuprinde fiecare comandă, fiecare cheie de rețetă și fiecare cod de ieșire.