Unit tests need to: A. Be taken seriously by the dev team. B. Taken at least moderately seriously by management. Getting the unit tests passing isn't always the

Unit tests need to: A. Be taken seriously by the dev team. B. Taken at least moderately seriously by management. Getting the unit tests passing isn't always the most important thing this very second, but they do need to be something we get back to. C. Run automatically, and preferably as a gateway to the commit process. Some sort of automatic continuous integration thing is critical. I have a lot of smaller projects rather than one big project so my CI is often just a git pre-commit hook. This works fine at a small scale; if "CI" is less than ten seconds I think it's advantageous to keep it as local to the dev as possible rather than shoving it off to some external server to complain later. Without these things, they're mostly theatre. With them, they're an incredibly valuable aspect of development that I don't intend to ever develop with ever again, by which I mean, if I do end up taking a job where this wasn't already in place, and I'm not allowed to put it into place, I will shortly be at a new job. Life is too short for the kinds of stupid debugging you have to put in to an untested, uncovered code base. (I don't mind debugging in general. It's a fact of the job. But that pull your hair out every single time, that's an uncovered code base.)