I use characterisation testing all the time, in a perhaps unusual application: Checking the behaviour of "Page Objects" (classes used to model the application-under-test in GUI-level automated testing) when the application-under-test has changed. That's right: Automated [characterisation] tests for my automated [GUI] tests! It makes GUI testing oh so much easier to maintain. I wrote it up here: https://david.rothlis.net/pageobjects/characterisation-tests

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.

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

    rwildcard = $(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2) $(filter $2,$d))

    rwildcard=$(foreach d,$(wildcard $1*),$(call rwildcard,$d/,$2) $(filter $(subst *,%,$2),$d))

    $(call rwildcard,,*.c)

    $(call rwildcard,,%.c)

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

For those who don't know, here's a list of stuff I've written over the years.

https://blog.jgc.org/2013/02/updated-list-of-my-gnu-make-art...

And the hard copy version: https://nostarch.com/gnumake

PS I really like the layout of your blog.

Try to learn anything in depth these days and either you're deciphering a dense yet incomplete manual, or googling until eternity. Make is a great example, as even though they have a useful manual, good luck figuring out how to apply it to your problem. Wikis don't quite cut it either. We need a different data model for knowledge sharing.

I keep wondering about doing a video series explaining GNU Make from the ground up.

[0]: https://github.com/couchand/wayfinder/blob/1dc58a1130bc17941...

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.

I haven't come across this kind of terminal playback on the web before, seems a bit more bandwidth efficient and snappier than video or gifs.

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

    this is a nice post
    i'm not sober on hn
    fixed width code font please

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.

It seems possible to me that it’s actually the use of a true serif monospace font (>95% of monospace fonts used these days are sans-serif, and >95% of the remainder are slab serif) that’s throwing you off, more than the strict monospacedness of it, and I’d like to try that hypothesis out.

(In early development of the visual style, I used only the font with no spacing or colour hints, but I found the monospace Triplicate too similar to the serif Equity, so that it was sometimes not quite clear enough that it was code; that was the reason why I put the background colour on inline code rather than only on code blocks, even though that wouldn’t be done in a printed manuscript, which is a style I am loosely imitating in part.)

Ultimately you're never going to win a discussion about type-faces because they're entirely personal preference. For example I find most proportional fonts to be too narrow and harder to read so much prefer the typically wider glyphs of monospaced type-faces. To the extent that the font I used on one of my blogs was rounder letters. I then had complaints that others found it "unreadable" and preferred something narrower.

I'm sure there will always be a sweet spot where more than average number of readers will be content however the web would be a little duller if everyone converged on that same type-face. So I'm willing to take a marginal hit on readability (and let's be honest, the different is almost always only marginal) for the sake of websites having their own personalities. The alternative if people can just toggle Reader View in Firefox (or whatever the equivalent is in other browsers)

While I much, much prefer proportional it's simply that indented stuff after text didn't line up properly in it eg.

stuff = 23

more stuff = 99

x = 41

(edit: sorry HN is messing up the indenting even further, but you know what I'm getting at)

Also my magit popup buffer is all ziggy-zaggy instead of properly column'ed. I can live with that. Edit - and git log which relies on fixed-width to show properly gets all bollixed.

In your case I can't see your code suffering at all from these problems, so I'm fine with it.

The niceness of proportionals may be enough for me to go back to it. I don't know yet.

Further edit: thanks for the article!

Yet one of the things I really like about Poly is how it decreases width. Disabling Poly would slightly harm layout on https://chrismorgan.info/blog/rust-fizzbuzz/ where I have code side-by-side, increasing the width required for the full layout without wrapping from ~1500px to 1600px. Ah well. It’s not critical, just makes me a little bit sad. (Admittedly I could get much of that back with `tab-size: 3;` instead of `tab-size: 4`, but that would doubtless make people baulk too. And I’m not going `tab-size: 2` except on small displays.)

  Please rip out my eyes
  I can no longer read this
  Polyspaced madness

Its not as slick or concise as the solution proposed here, but it shows that the approach is viable for medium-large projects.

One trick I found helpful was using JSON to serialize test results instead of unstructured plain text.

Test results stored as JSON are much easier parse and therefore process. You can quickly whip up programs that verify the tests satisfy invariants, diff the tests and filter out expected test changes from unexpected test changes.

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.

I've been using cram (also written in Python) for a private project and been mostly happy with it: https://bitheap.org/cram/

i've been using cram for everything i write for what feels like a decade (it'll be 10 years old in september), and though it has it's limits, i bitch and moan about it very little given how much i rely on it. if you'd know me you'd recognize that this is a huge endorsement, i'm quite vocal about my disdain for most software in existence. :)

edit: s/i'll/it'll/ rofl

edit: url: https://bitheap.org/cram/

https://bazel.build/

    $(patsubst %.stdout,%.stderr,$@)

    $*.stderr