Using `make` and `git diff` for a simple and powerful test harness

This would require auto-mocking of all subsystems to prevent side-effecting functions from sending email & SMSes.

I started doing this a few years ago while working on a Sphinx extension that defines new directives but also customizes a few output targets (including two ~plaintext output targets).

It's not only useful to avoid accidental output changes, but it's essential for iterating with confidence that tiny changes at the code level affected the output as-expected over a mostly-representative fraction of the documentation set.

I didn't have a term for it at the time. I guess about a year later I bumped into snapshot testing, but that's always felt like more of a metaphor.

Thanks for all the stuff you’ve written about Make: I’ve enjoyed reading quite a lot of it!

I’m not completely sold on using a separate crate and build.rs how you have, but it looks like it’ll yield a good usable result. A couple of related things you might be interested in: compiletest_rs, trybuild.

The most popular thing in this space nowadays is asciinema, mostly used by embedding it from asciinema.org, but I prefer my thing.

I use the Poly variant by default, only disabling it in places where the monospacedness matters for layout purposes, e.g. the terminal recording in this article (because of Vim), and Rust compiler output in some of my other articles. The Poly variant does things like make i, l and space a little narrower, and m a little wider, which makes casual reading more comfortable than a strict monospaced font.

I do this because I believe that monospacedness is substantially overrated in most places, and that most things actually look better not strictly monospaced. I contemplated not even using a monospace-style font at all but decided that was probably going too far for most people. (And as a Vim user I necessarily work in a monospaced text editor; but if it weren’t for that, I’d probably go full proportional.)

So I’m curious if you have further feedback on this matter and why you find fault with what I’m doing. It may influence what I do.

This aspect of expected and unexpected test changes is even more important than the diff part in my opinion. It allows you add failing tests immediately once you get the bug report and you notice if you fix something accidentally.