I've been using a program I wrote for 18 years now. The code today is not the same as the code 18 years back. I have slowly modified the code as ideas for new features come up, old features removed because they aren't used anymore, and foundational code rewritten as I found better implementations (or the previous implementation was a mistake [1][2]. Making a sweeping change (like re-implementing some core code) is dangerous because of the threat of new bugs, which is why tests are important (although I tent to prefer integration tests over unit tests).
[1] I used to have an error logging mechanism in place that would record where in the code the error happened (in addition to other information) and how it propagated up through the code.
While it wasn't that hard to use, per se, it was bothersome when I had to add an error (each error had a unique ID and because of language issues and tooling, that was a manual process). And it really never paid back its implementation cost in terms of reporting, so I finally ripped it out.
[2] I had my own version of C's FILE* [3] that ended up being a horrible abstraction---it was so confusing that I could never remember how to use it, and I wrote the code. I got fed up with it, and ripped that out, replacing it with native IO calls.
[3] For stupid reasons now that I think back on it.
The simple way to say it is that once your code gets too complicated to keep all the execution paths in your head (sooner than you think), tests are what enable you to make sure you didn't forget an assumption you made about how it should work.
Do you like going back to manually verify things still worked after you make a foundational change? Or do you just trust yourself to know you've not impacted anything negatively? Do you honestly believe that's good use of your brain power even if true? Do you enjoy being married to that code? Because that's exactly what happens as nobody but you can work on it. That strategy works out well for employees to become key men and get big retention bonuses so there is some merit to your approach :-)
Not to mention the team impact to cowboy coding. It's a selfish approach to software development and is often undertaken by bully developers that say things like "use the source" as a way to make you feel dumb for not wanting to spend all day trying to untangle their likely insane code. All because they were too lazy to use a little empathy and be a good teammate.
To recap: Tests document and improve your design, verify functionality, provide leverage to accelerate development, and reduce "bus factor" risk. I don't care what a small sample data set says to the contrary there's really little debate that when wielded properly these tools and techniques do improve software on multiple dimensions that go beyond the software itself and heavily impact the business.
20+ years of product development experience in lots of teams/products inform this opinion. Let's see the data on how your business grinds to a halt when these tools aren't used and the code base gets increasingly larger and complex and people leave. Tell me about how you don't need those automated tests as you approach technical debt bankruptcy and all your key people have left. "Use the source" is a terrible response to that problem.
Rewrites can be fun though so maybe that's the answer. It sure worked out well for Netscape. ;-)
Unit tests are a poor way to validate code behavior. 30+ years of development has taught me that validation tests within the code itself are far better.
1) They run whenever the product runs. Good logging code tells you when it fails, even on customers devices.
2) By being part of the production code, they are far easier to keep up to date as the code changes even through refactoring.
3) They don’t force you to change anything about how you code.
Why not just say that unit tests are a management methodology for mixed-skill teams? There's no need to invoke 'bully devs' just because inexperienced or un-conscientious developers exist.
[1] I used to have an error logging mechanism in place that would record where in the code the error happened (in addition to other information) and how it propagated up through the code.
While it wasn't that hard to use, per se, it was bothersome when I had to add an error (each error had a unique ID and because of language issues and tooling, that was a manual process). And it really never paid back its implementation cost in terms of reporting, so I finally ripped it out.
[2] I had my own version of C's FILE* [3] that ended up being a horrible abstraction---it was so confusing that I could never remember how to use it, and I wrote the code. I got fed up with it, and ripped that out, replacing it with native IO calls.
[3] For stupid reasons now that I think back on it.