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.
Heh, yeah, that's fair, although I think there's some nuance in terms: accidental changes (to things that were working) is a form of regression in my mind. Depending on how the codebase is structured, changing the tests to match the new desired behaviour might be trivial or might be excruciatingly complicated. These days (mentioned elsewhere in this discussion) I'm working on more embedded stuff, and the only time I'm generally writing unit tests are for things that shouldn't change.
As an example, last year I was working on a custom LoRaWAN stack. As I was building out the various pieces, I was writing tests to verify that the output from generally-pure functions came out as expected. (This packet) + (This key) = (This encrypted packet). Those kinds of tests help a ton for catching stupid mistakes.
I think a lot of people miss this point entirely. Before the unit test thing, I would always have a tester project, it just wasn't formal or automated.
I see good value in modern unit tests when you are building some sort of automation engine, rules engine, etc. But I think a lot of people see them as a hammer and everything is a nail.
Yup, in my domain (games) unit tests are common for functionality that is easily applicable to them (e.g. linear algebra libraries) then integration tests are more common for systems (e.g. testing collision systems integration with the game engine, do you get the right callbacks or whatever) but once you hit the game itself automated testing is not massively useful as it's usually painful to setup and maintain and only covers "does this case still work" with no information on how good the end product actually is.
IMO a lot of places have forgotten the value of manual testing in terms of not only finding bugs but actually understanding how the product is used. Games companies prize iteration speed in terms of how quickly you can test a change in situ because we as game makers need to verify our changes by playing the game. I'm making a multiplayer game right now so I need to make sure what I do works on the server and clients which usually necessitates three copies of the game running together. Then we playtest it with a larger group weekly and playtest with even larger groups less regularly.
My impression of a lot of modern development elsewhere is that as soon as automated tests are green the code gets punted into production which seems utterly bonkers.
