Caching is better than mocking
5 points by chrislloyd
5 points by chrislloyd
Basically golden files, right?
Somehow I hate the idea — maybe due to working for so long in the company where lots of tests were based on golden files. In big enough project it led to constant manual work of maintenance and manual overrides (when differences exist but not really matter). Even worse in the world of LLMs where results are varying even for same arguments!
Sorry to say, but I hate the idea, and I only wonder how it works for the author.
Probably depends a lot on how the caches are generated.
Been a few years but if it involves any delicate process that can easily go wrong - painful.
If it's as easy (and usually working) with make test-dummy && git commit then I don't usually see a problem.
My problem is more like: Some example files are nice, but if I explicitly build them as "materialized mocks" or mock some edge cases.. I don't see a big difference. Unless your mocks are just a small approximation and you're for example parsing this 5MB XML file that already covers 40% of your weird cases...
For network calls to third party APIs, as part of development, I will record the call (with my own library but it's just a minimalist clone of Ruby's VCR) then I just strip out any identifiable data (API keys, etc) and use that for testing.
We use an internal copy of https://github.com/golang/oscar/tree/master/internal/httprr :)
We used to use https://pkg.go.dev/github.com/google/go-replayers/httpreplay but httprr has fewer dependencies and a simpler format.