The thing that unit tests are really good for is providing a safety net when you make changes. And I love them. I have a few multi-year projects that sit and do

The thing that unit tests are really good for is providing a safety net when you make changes. And I love them. I have a few multi-year projects that sit and do their thing for months at a time with no changes; when I come back to them with a client request, the test suite is awesome for making sure that whatever I just changed didn't break something else (alternatively, the tests point out an assumption I made when writing the tests and the test needs to be changed). Either way, I appreciate it. Especially when there've been changes done by other people that I wasn't aware of. Buuuuut... a lot of the personal projects I've worked on have zero unit tests. Maybe they have a couple of tests around a complicated algorithm, but mostly... no automated testing. What they do have though is a) version control, and b) a fast-iteration platform underneath them. They're also generally well factorered into small chunks. As an example, I have a package that takes an org-mode file and extracts time entries to drive into time tracking software a client uses. Written in Lisp, zero tests. Every month I fire it up, look at the table of entries it's about to post, and hit "go". Looking at the table of entries provides two sanity checks: first, that I properly logged my hours that month (I'll occasionally forget to clock out for a weekend and rack up a 48 hour time log), and second, that it didn't encounter a bug while doing the processing. As of around September of last year, this program is done, and does its job perfectly every month. Another example, also in Lisp, is used for making estimates for my clients. I give it a list of tasks with 3-point estimates, it churns through and calculates all the means and standard deviations, generates a file for Pandoc to consume, and spits out a PDF. I use it every couple of months. No tests, all done inside the SBCL repl. I obviously proofread the output PDF before sending it to a client, but that's again to check for bugs and to check for brain farts. I've worked on great codebases that have giant test suites, and I've worked on terrible codebases that have giant test suites. And likewise for no test suites. While I appreciate the sentiment, I think it's dangerous to talk in absolutes like that. While I agree there is probably some degree of correlation between whether or not a codebase has a unit test suite and whether it's good code, writing unit tests does not intrinsically make the codebase good, and not writing unit tests does not intrinsically make a codebase bad.