Anecdote time: I worked on a project with a senior dev who was really into unit testing and only unit testing. The software had to be fully tested as tiny little lego bricks with mocks galore. Because "if all the pieces were correct, the combination had to be correct" - his words. (I guess he'd never considered emergent behavior)
I'll never forget the cycle, after staunch objections to integration/e2e/manual tests and zealously insisting on full unit test coverage, the senior dev deployed changes ... boom. The process failed hard minutes after start because there was a bug in main. Full production outage. A bug so obvious we should have caught it by eye. Clearly, in the weeks developing the feature, he had never bothered to even run the application. Each part was fully polished in isolation but utterly failed when integrated into an application.
The way I've come to think of it: Unit tests are for libraries, a closed world where you can neatly define all inputs and outputs. Integration/E2E tests are for applications, an open world which require systems thinking, simulations not proofs. Know which world you're working in!
That doesn't really sound like an indictment of unit tests. I don't really understand why someone would meticulously write a bunch of unit tests and then wait to prove them on a production deploy?
Unit and integration tests serve different purposes and one isn't necessarily better than the other.
It's an indictment of writing only unit tests. If the system also had integration tests this would likely have been caught, but even more important is the lesson that no amount of automated tests is an excuse not to actually try using your software yourself.
Anecdote time: I worked on a project with a senior dev who was really into unit testing and only unit testing. The software had to be fully tested as tiny little lego bricks with mocks galore. Because "if all the pieces were correct, the combination had to be correct" - his words. (I guess he'd never considered emergent behavior)
I'll never forget the cycle, after staunch objections to integration/e2e/manual tests and zealously insisting on full unit test coverage, the senior dev deployed changes ... boom. The process failed hard minutes after start because there was a bug in main. Full production outage. A bug so obvious we should have caught it by eye. Clearly, in the weeks developing the feature, he had never bothered to even run the application. Each part was fully polished in isolation but utterly failed when integrated into an application.
The way I've come to think of it: Unit tests are for libraries, a closed world where you can neatly define all inputs and outputs. Integration/E2E tests are for applications, an open world which require systems thinking, simulations not proofs. Know which world you're working in!
That doesn't really sound like an indictment of unit tests. I don't really understand why someone would meticulously write a bunch of unit tests and then wait to prove them on a production deploy?
Unit and integration tests serve different purposes and one isn't necessarily better than the other.
It's an indictment of writing only unit tests. If the system also had integration tests this would likely have been caught, but even more important is the lesson that no amount of automated tests is an excuse not to actually try using your software yourself.
Both is good.
Your Website seems to be messing with browser history. Back button will not take you back to HN.
Skimmed through this. One heading is "The gap was never coverage. It was wiring.". Smeḷls very AI sloppy, won't bother reading...
I used to read anything and everything on HN, but my allergy to slop has made me stop doing that. I suppose that's a good thing?