Live data from Hacker News

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

chrismorgan.info

31–40 of 48 posts

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

#31

This technique is also known as characterisation testing, golden-master testing, snapshot testing, and probably other names too. I recommend looking into https://approvaltests.com/ (already mentioned by another commenter). 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 test…

I recently found it useful for an approximation algorithm. Since it was an approximation, it didn't really make any hard guarantees on the output for a given input, but snapshot testing at least made it very clear when a change affected the output and to what.

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

#32

This technique is also known as characterisation testing, golden-master testing, snapshot testing, and probably other names too. I recommend looking into https://approvaltests.com/ (already mentioned by another commenter). 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 test…

Thanks for the term "characterisation testing".

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.

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

#34
cram is a very good tool for testing in this manner: a test file is basically a copy/paste of a terminal window, deviations from expected behavior are represented using diffs, and `cram -i` will prompt you to update the test file with actual output. and it supports globbing and regular expressions for fuzzy matching.

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/

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

#35

Earlier quoted context omitted.

I think one of the best reasons to use a monospaced typeface is that it is a fairly strong and accurate signifier of code. Of course, in this case you have special highlighting for it that makes it less useful, but in general I think that it really helps. (Plus there are a couple of other, minor benefits probably not worth listing here.)

As mentioned elsewhere I've been using proportional for code and it's very nice but for a small drawback. I'd say give it a try for a couple of days and see.

[deleted]

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

#36

it's my friday, here's a haiku for you: this is a nice post i'm not sober on hn fixed width code font please

The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ 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…

Yikes, one hundred twenty dollars for a font? That's quite expensive. Have you found it to make that great a difference?

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

#37

Earlier quoted context omitted.

The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ 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…

Yikes, one hundred twenty dollars for a font? That's quite expensive. Have you found it to make that great a difference?

I use Triplicate, Concourse and Equity extensively. Equity, there are surprisingly few fonts like it in its organic feel and faithfulness to the old art of printing. (This doesn’t convey as much as I’d like, but I lack the terms of art to describe what I mean properly.) Triplicate, well, it’s the only good true serif monospace that I know of, and I like that. Each font fills a niche that I very much appreciate. I reckon they were worth buying on their own merits, but it was also then a way of supporting Matthew Butterick’s project https://practicaltypography.com/ which I strongly approve of as a project.

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

#38

This technique is also known as characterisation testing, golden-master testing, snapshot testing, and probably other names too. I recommend looking into https://approvaltests.com/ (already mentioned by another commenter). 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 test…

I’m really glad to have these terms of art; now I know what to search for to find similar things. Thanks!

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

#39

it's my friday, here's a haiku for you: this is a nice post i'm not sober on hn fixed width code font please

The code font I use is Triplicate: https://mbtype.com/fonts/triplicate/ 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…

It's a beautiful font and I didn't notice that it wasn't fixed-width. You whole site design is awesome IMO.

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

#40
post #4

Earlier quoted context omitted.

I second the mono space for code suggestion. I guess my brain is wired to see when characters are offset slightly as wrong. It’s a bit unsettling.

To you and anyone else with this opinion: try disabling the `code { font-feature-settings: "ss01" 1, "ss02"; }` rule in the CSS, which will disable the Poly variant, and let me know how it feels. 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 stri…

Disabling `code { font-feature-settings: "ss01" 1, "ss02"; }` made a marginal improvement for me but it was only marginal. The bigger issue I had was the type-face was too large.

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)

Post reply on HN