Wofür Leute es einsetzen

Fünf Aufgaben, die in fast jedem Projekt vorkommen, das Dateien von Menschen annimmt, und der Befehl, der jede erledigt. Jedes Beispiel unten läuft so, wie es geschrieben steht.

Upload-Limits

Testen, ob ein Dateigrößenlimit dort durchgesetzt wird, wo es angegeben ist

Ein Limit sind drei Testfälle, nicht einer: knapp darunter, genau darauf und knapp darüber. Die von Hand zu bekommen heißt, Byte-Zahlen auszurechnen und zu hoffen, dass man sich nicht um eins verzählt hat. Fordere stattdessen das Set an:

tfg generate --preset size-boundaries --limit 1mb --spread 1B --format pdf --out ./edges

Du bekommst drei echte PDFs mit 1048575, 1048576 und 1048577 Bytes und ein Manifest, das sagt, dass die ersten beiden akzeptiert und die dritte wegen size_limit abgelehnt werden soll. Dein Test liest die Erwartung, statt dass du drei Assertions von Hand schreibst - und wenn sich das Limit ändert, änderst du eine Zahl und startest neu.

Dasselbe geht ohne Preset, wenn du ein einzelnes Grenzen-Set inline willst:

tfg generate --format png --boundary 5mb --out ./png-edges

Continuous Integration

Fixtures aus dem Repository heraushalten, ohne sie zu verlieren

Große binäre Fixtures machen ein Repository langsam beim Klonen und mühsam beim Review, und niemand sieht, was sich geändert hat, wenn eine ersetzt wird. Ein Rezept sind ein paar hundert Zeichen YAML, die die identischen Dateien neu erzeugen - Byte für Byte, auf jedem Rechner - weil jede Datei aus dem Seed des Laufs abgeleitet wird.

- 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

Jedes Ende hat einen eigenen Exit-Code, sodass eine Pipeline ein schlechtes Rezept von einem vollen Datenträger und von einer Abweichung bei der Prüfung unterscheiden kann. Ein fehlgeschlagener Lauf gibt nichts auf der Standardausgabe aus, wodurch ein Log-Parser einen Fehler nicht als Daten liest.

Skalierung

Herausfinden, was passiert, wenn der Ordner groß ist

Importroutinen, nächtliche Jobs und Verzeichnislisten verhalten sich bei zehntausend Dateien anders als bei zehn. Aus einem Bereich gezogene Größen lassen das Set wie echten Datenverkehr aussehen statt wie zehntausend identische Dateien, und die Ziehung kommt aus dem Seed, das Set ist also morgen dasselbe.

tfg generate --format log --size-range 1kb-8kb --count 10000 --out ./fixtures

Prüfe, was ein Lauf kosten würde, bevor er etwas schreibt, was zählt, wenn die Summe in Gigabyte gemessen wird:

tfg generate --format log --size-range 1kb-8kb --count 10000 --dry-run

Ein Lauf, der größer ist als der freie Platz auf dem Datenträger, wird vor dem ersten geschriebenen Byte abgelehnt, statt den Datenträger zu füllen und auf halbem Weg zu scheitern.

Einen Entpacker mit einem Archiv testen, das wirklich Dateien enthält

Ein leeres Archiv mit der richtigen Endung beweist nichts über Code, der es öffnet und durchläuft, was darin ist. Deklariere den Inhalt, und das Archiv enthält ihn wirklich:

targets:
  - id: bundle
    format: zip
    contains:
      - format: txt
        count: 200
        size: 4kb

Verschachtelungstiefe, Eintragszahlen und die Größe dessen, was darin liegt, sind alles Dinge, zu denen eine Importroutine Meinungen hat, und so findest du heraus, welche das sind.

Parser und Viewer

Prüfen, dass dein eigener Code ein Format so liest wie echte Software

Jedes Format hier wird vor der Auslieferung mit einem unabhängigen Leser geprüft - ein PNG wird geöffnet und seine Pixel verglichen, ein DOCX von separaten Bibliotheken zurückgelesen, ein Archiv entpackt. Das heißt, eine Datei, die dein Parser abweist, ist ein Befund über deinen Parser, nicht über den Generator.

tfg generate --format docx --size 300kb --set paragraphs=120 --out ./documents
tfg generate --format xlsx --size 2mb --set rows=400 --set columns=6 --out ./sheets

Die Formate-Seite listet die Einstellungen jedes Formats und die kleinste Datei auf, die es sein kann.

Anleitungen

Zwei davon im Detail

Beschädigte Testdateien - eine absichtlich kaputte Datei in exakter Größe, mit dem Manifest als Angabe, was mit ihr geschehen soll.
Testdateien in CI - ein GitHub-Actions-Workflow, ein GitLab-Job und die Exit-Codes, die einen Build scheitern lassen.

Für wen das gedacht ist

QA-Engineers, Testautomatisierung und alle, deren Code ein Upload-Formular, eine Importroutine, einen Parser oder ein Speicherkontingent hinter sich hat. Es läuft auf einem Rechner ganz ohne Netz, was in einer abgeschotteten Unternehmensumgebung zählt, wo ein browserbasierter Generator keine Option ist.

Herunterladen Quellcode ansehen

Kostenlos und Open Source, GPL-3.0. Keine Anmeldung nötig. Die Downloads für Windows und macOS sind signiert und starten ohne Warnung.