> 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.
Of course, those are good examples. And I do write tests for stuff like that. But it's a tiny, tiny part of what the average front-end web app dev is doing on a day to day basis. My claim isn't that testing is useless. It's that you can get 90% of the benefit from doing probably 10% of what the average dev (in my field, YMMV if you're not a FE web dev) is doing at the moment, and the business value of testing falls off a cliff once you hit the low hanging fruit.
Lemme go back to the same PG article, again, cause it's that good.
"A couple years ago a venture capitalist friend told me about a new startup he was involved with. It sounded promising. But the next time I talked to him, he said they'd decided to build their software on Windows NT, and had just hired a very experienced NT developer to be their chief technical officer. When I heard this, I thought, these guys are doomed."
If I walk into an interview at a startup, and they have 100% unit test code coverage with a nice suite of integration and end-to-end tests, snapshot testing, nice contract tests, the absolute works, all for their 50 customers generating $5k monthly revenue, my first thought is they're probably fucked. It might be a really nice place to work, but if I want job security I'd be going somewhere bigger, and if I want shares I'd much rather be in the share house down the road with the guys that polished off 3x as many features in a couple of weekends of hacking.
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.