Test and Code is a real gem of the software podcast world. It's all steak and no sizzle. And I can prove I thought so even before I got the odd dose of flattery that is hearing one's slightly controversial beliefs affirmed on a respectable platform. Episode 191 covered, among other things, the intersection of static site generation and testing.
My thoughts about writing the SSG powering this site grew out of my revised thoughts about testing. I used to have an idealized view of testing: software breaks into atomic components; you should test all the atoms thoroughly; you should also test various relations among those atoms. I'm more pragmatic now. As I find things I need to be true of my code, I write tests for it. And when something breaks in my code, I write a test to check for that failure. The latter I think of as "lazy testing," not in the psychological sense of "lazy" but as in "lazy evaluation," "lazy deletion," and the like. There are applications where finding and testing every edge case matters. Often, though, a unit of testing time is better spent elsewhere.
A surprising benefit of this approach is that it keeps me focused on the question of how I can actually make sure the software works. The surprising part is that we can lose focus on that question in the first place. But we can. It's all too easy to become a fanatic about testing in the Santayana sense, "redoubling your efforts when you have forgotten your aim."
Relatedly, Okken and Wisti make a point I think is underrated: learn coding by coding smoething that matters to you. If you are doing something you care about, it's easier not to forget your aim, and to avoid that sort of fanaticism. They even echo one of my examples: using Pytest to make sure links work.
Wisti seems to be on the same journey that, for me, terminated in writing my own SSG. ("Terminated" in the sense of "continuing indefinitely, but more pleasantly.")