> how much of it do I write unit tests for? Zero. I can't quantify why. I just know intrinsically that they're useless and it's a waste of time. I just know that 95% of my code works and I know what the 5% I'm unsure about is
Surely if you were, for example, writing an automated trading system, or something that handles money, or anything that actually impacts the running of a business in a bigger way than the website being down you would see the value in writing tests, right? Even in the situation that the website is the product, don't you see the value of having tests to make sure that future changes don't break existing behavior without having to run through an exponentially expanding manual test regime?
For me tests are about catching regressions and verifying behavior, e.g.;
* I can visually see by reading the code that if someone submits an order that breaches a risk limit, it's rejected. Still, I wouldn't feel comfortable letting that system trade until I had verified with both a unit test that handles the generic 'reject a number > risk limit' _and_ an integration test that verifies 'I send N different types of orders into the system, where N/2 are above the risk limit. Which orders pass the risk check?'
* I've done some refactoring to some low level connection logic to handle some rare condition that last happened on Friday at 2300. I wouldn't release the code with the refactoring until I can verify with a test that both the new condition is handled, and all of expected unchanged behavior is unchanged. Without a test suite, I would have to spend a day setting up environments and testing each invariant, which is a waste of time for something that I can automate and have more confidence in. Also, without a test suite, how would I know that a change in the future wouldn't result in me having to come online at 2300 on a Friday because of a regression that someone didn't catch in their manual testing?
* Someone has submitted a PR that modifies how often our log files get rolled - without a test suite to verify the failure modes, I would never let that get to production. Why would I want to risk losing log files, at the cost of spending 30 minutes writing a test for the failure modes (at least, the ones I know about, which is still better than none because testing isn't a zero-sum game)?
Having the "it's going to fail anyway, and I already know where" attitude is a terrible way to approach risk management (which is, ultimately, what testing represents) IMO. It might be fine in certain domains, but in others its a quick way to tank a company.
I definitely agree that it's not worth testing everything (e.g. CI scripts - if they work, they work!), but for actual business logic or infrastructure not writing tests is straight up negligent. Even if you're certain that the code does what it says and you can keep all of the failure modes in your head at once as you make changes, I guarantee that someone else on your team (this could be you in six months) doesn't, or can't.