https://arran4.github.io/blog/tags/refactoring/Recent content in refactoring 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>.Fri, 02 Oct 2026 11:55:00 +1000https://arran4.github.io/blog/post/2026/051-large-go-tests-should-read-like-scenarios/Fri, 02 Oct 2026 11:55:00 +1000technicalblog123@arran4.com (Arran Ubels)https://arran4.github.io/blog/post/2026/051-large-go-tests-should-read-like-scenarios/A long test is not automatically a bad test. End-to-end and integration scenarios sometimes need substantial setup and several assertions. The problem begins when the test body stops explaining the behaviour and becomes mostly mechanics: temporary files, archive writers, mock HTTP routing, hashes, cleanup, environment restoration, and repeated if err != nil blocks. The standard I want is: the top level of a test should read like a scenario even when the machinery underneath it is complicated.