Testing Files Generator
Português (Brasil)

Como gerar arquivos de teste em um pipeline de CI

Uma fixture binária em um repositório fica para sempre no histórico, não pode ser revisada em um diff e deixa de ser viável quando o arquivo é grande. Gere os arquivos dentro do pipeline a partir de uma receita. A receita é texto, os bytes saem iguais a cada vez e um último passo prova que nada mudou.

A resposta curta

Instale o tfg, rode tfg generate fixtures.yaml --out ./fixtures antes dos testes e tfg verify ./fixtures/manifest.json depois. Os dois passos fazem o build falhar sozinhos, com um código de saída que diz o motivo.

Por que não commitar

Por que uma fixture não deve morar no repositório

O que se commita é a receita. A mesma receita e a mesma semente gravam os mesmos bytes em qualquer máquina, então o arquivo gerado no pipeline é o arquivo que você tinha no notebook.

A receita

Uma receita que mora junto dos testes

Esta grava vinte e cinco faturas que devem ser aceitas e duas imagens acima de um limite que devem ser recusadas, e o manifesto registra as duas expectativas: 

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 verifica a receita sem gravar nada e nomeia todos os problemas de uma vez.

GitHub Actions

Um workflow que instala a ferramenta e constrói as fixtures

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

A linha da soma de verificação compara o arquivo com verify-SHA256SUMS.txt da mesma versão. A versão está fixada, então uma versão nova nunca altera um build que você não mexeu.

GitLab CI

A mesma coisa como job do 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 fica vermelho

O que faz um passo falhar, e por quê

Cada final tem o seu próprio código de saída, então o passo falha sozinho e o log diz qual foi. Os que um pipeline encontra:

Uma execução que falhou não imprime nada na saída padrão, então um analisador de logs nunca toma um erro por dado. A tabela completa está na página de documentação.

PowerShell

Um script PowerShell precisa de mais uma linha

O PowerShell não leva o código de saída de um programa para fora de um arquivo .ps1. Rode um com -File e o script responde 0 mesmo quando a ferramenta lá dentro recusou o trabalho, então um build que deveria ficar vermelho fica verde. A última linha é a correção inteira: 

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

É assim que o PowerShell se comporta, não algo desta ferramenta. cmd, bash e zsh não precisam de mais nada.

Vários jobs

Compartilhando as fixtures entre jobs

Em geral não é preciso enviá-las. Como a mesma receita grava os mesmos bytes, cada job pode rodar o seu próprio tfg generate, que é mais rápido que um upload e um download. Quando um job precisa receber arquivos de outro, rode tfg verify no manifesto depois da transferência, e ele diz se o que chegou é o que foi gravado.

A seguir

Para onde ir daqui