人们用它来做什么

上传限制

测试文件大小限制是否在声称的位置生效

一个限制对应三个测试用例，而不是一个：刚好低于、恰好等于和刚好高于。手工做这些意味着计算字节数，并祈祷自己没有算错一位。不如直接请求整套文件：

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

你会得到三个真实的 PDF，大小分别是 1048575、1048576 和 1048577 字节，以及一份清单，说明前两个应被接受，第三个应因 size_limit 被拒绝。你的测试读取预期，而不是由你手写三个断言，限制改变时，你只需改一个数字再重新运行。

如果你只想要一组内联的边界文件，不用预设也可以做到：

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

持续集成

让 fixture 留在仓库之外又不丢失

大型二进制 fixture 会拖慢仓库克隆，也让评审变得别扭，而且替换其中一个时没有人能看出改了什么。配方只是几百个字符的 YAML，就能重建出完全相同的文件，在任何机器上逐字节一致，因为每个文件都由运行的种子派生。

- 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

每种结束方式都有自己的退出码，所以流水线可以区分配方错误、磁盘已满和校验不一致。失败的运行不会在标准输出上打印任何内容，这样日志解析器就不会把错误当成数据。

规模

弄清文件夹很大时会发生什么

导入程序、夜间任务和目录列表在一万个文件时的表现与十个文件时不同。从范围中抽取的大小让文件集看起来像真实流量，而不是一万个完全相同的文件，并且抽取来自种子，所以明天文件集依然相同。

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

在运行写入任何内容之前先查看它的开销，当总量以 GB 计时这一点很重要：

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

比磁盘可用空间更大的运行会在写入第一个字节之前就被拒绝，而不是把磁盘写满再半途失败。

压缩包

用真正装有文件的压缩包测试解压程序

只有正确扩展名的空压缩包，无法证明任何关于打开它并遍历内容的代码的事情。声明内容，压缩包就真的包含它们：

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

嵌套深度、条目数量和内部内容的大小，导入程序都有自己的看法，而这正是你弄清这些看法的办法。

解析器与查看器

检查你自己的代码读取格式的方式是否与真实软件一致

这里的每种格式在发布前都用独立读取器验证过：PNG 被打开并比对像素，DOCX 由另外的库读回，压缩包被解压。这意味着你的解析器拒绝的文件，是关于你的解析器的发现，而不是关于生成器的。

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

格式页面列出了每种格式接受的设置，以及每种格式能达到的最小文件。

指南

其中两项的详细说明

• 损坏的测试文件 - 一个故意弄坏、大小精确的文件，应对它做出的处理写在清单里。
• CI 中的测试文件 - 一个 GitHub Actions 工作流、一个 GitLab 作业，以及让构建失败的退出码。

适合谁

QA 工程师、测试自动化，以及代码背后有上传表单、导入程序、解析器或存储配额的所有人。它可以在完全没有网络的机器上运行，这在基于浏览器的生成器行不通的封闭企业环境中尤为重要。

免费开源，GPL-3.0。无需注册。Windows 和 macOS 的下载包已签名，启动时没有警告。