I think the bigger problem, conceptually, is the assumption that tests are necessarily something you write and not something you do. There's nothing wrong with having automated tests, but they're a supplement to hands-on testing, not a replacement for it.

Informal and manual testing was a thing back then, though. Building a large project is usually a good, nearly exhaustive test suite for a build system.

Also, if memory serves, things that I had to deal with in late 1980s and early 1990s were vastly simpler than what is normal today. Manual testing was more feasible.

But Quicklisp exists today. Are you suggesting testing is unnecessary or ineffective? If it is effective, why wouldn't Quicklisp use it?

>But Quicklisp exists today.

So? Tons of the software of the 70s and 80s exists today too. In COBOL form, it powers some of the more critical banking, government, etc, systems. In C form, it powers just about everything else.

>Are you suggesting testing is unnecessary or ineffective?

Of course it's ineffective. It can only prove the present of errors, not their absence.

>If it is effective, why wouldn't Quicklisp use it?

Because the need for testing also depends on how often you refactor and change your code, and how many bugs you're likely to put in it in the first place (based on the complexity of the domain, your skills, etc). I'd say both of those things are no issues for Quicklisp.

So, if having no tests works for Quicklist, and the program doesn't have many bugs people complain about, then that's it.

If a codebase works, is used, and doesn't seem to have bugs people complain about, we should also consult with reality when deciding if it's worth our time to write tests for it, not just some a priori ideology that they're necessary.