Integrated Tests Are A Scam

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".

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.

---

[1] http://www.sqlite.org/testing.html

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.

Defect free code is a scam.

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.