https://arran4.github.io/blog/tags/fstest/Recent content in fstest on Arrans Technical blogHugo -- gohugo.ioentechnicalblog123@arran4.com (Arran Ubels)technicalblog123@arran4.com (Arran Ubels)Arran Ubels. This work is licensed under a <a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.Thu, 17 Sep 2026 12:08:00 +1000https://arran4.github.io/blog/post/2026/047-choosing-go-filesystem-test-fixtures/Thu, 17 Sep 2026 12:08:00 +1000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/047-choosing-go-filesystem-test-fixtures/I already have broader references for txtar fixture systems, scaling txtar suites, and testing filesystem-heavy Go code. The missing piece is a smaller decision guide: when should a test use a plain embedded file, fstest.MapFS, or a txtar scenario? The answer is mostly proportionality. Use the least elaborate representation that still makes the case readable, deterministic, and easy to extend. A practical selection ladder A useful default is: Test shape First choice One small input/output pair literal data or go:embed Directory structure matters more than file payloads fstest.