I don't think that integration testing is sufficient (you will never catch every bug by writing tests - programming is too complex to expect any one coder to be perfect all the time). I'd also argue that writing too many integration tests can become a burden - having to change hundreds of tests when a site/app changes is tedious and time-consuming.
However, that doesn't mean that integration testing is useless. Writing a few tests to verify that mission-critical functions (like website registration) are working can save you when something goes wrong, and it's more efficient than doing manual regression testing every release.
Lastly, I really wish the author would give suggestions for what he considers to be a better approach to testing, beyond "integration testing sucks and is a scam".
Lastly, I really wish the author would give suggestions for what he considers to be a better approach to testing, beyond "integration testing sucks and is a scam".
I'm a bit confused what he's trying to say here. He seems to be arguing that full branch coverage is needed for thorough testing, but then argues something to the effect of "it's too hard."
So, what are we supposed to do? Not test? Not test "thoroughly"? Write 1084x as much test code as production code[1]? He provides no alternative.
I think the point is something like "don't unit test the system as a whole". Black box testing is great and most definitely should be used, but should be kept very high level and unit tests should be kept very small and granular.
The author's idea of branch coverage seems mixed up. I've worked on avionics at the strictest safety level. We had to test every branch and every combination of conditions for the branch, but every combination of branches up and down the code path was not a thing.
Randomised testing?? 1000000..... tests take a small amount of time to write.
Not saying thought out tests are worst, just if you really want to go down the road of testing amazing amounts of options there are options, personally rare events who cares, but automation can find things you didn't think of if you can't write quality tests.
The author is focusing catching errors with tests too much, he seems to miss the point that the difficulty of writing adequate unit tests is a symptom of bad design.
However, that doesn't mean that integration testing is useless. Writing a few tests to verify that mission-critical functions (like website registration) are working can save you when something goes wrong, and it's more efficient than doing manual regression testing every release.
Lastly, I really wish the author would give suggestions for what he considers to be a better approach to testing, beyond "integration testing sucks and is a scam".