Integrated Tests Are A Scam(blog.thecodewhisperer.com)
blog.thecodewhisperer.com
Integrated Tests Are A Scam
http://blog.thecodewhisperer.com/2010/10/16/integrated-tests-are-a-scam/
4 comments
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".
He has more articles on better approaches than integration tests, but I haven't read them yet so I can't say if they answer your questions sufficiently: http://blog.thecodewhisperer.com/blog/categories/integrated-...
He has more articles on better approaches than integration tests, but I haven't read them yet so I can't say if they answer your questions sufficiently: http://blog.thecodewhisperer.com/blog/categories/integrated-...
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
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
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 has several other articles on the subject that I have not read yet, so I'm not sure if I've got a full understanding of his point yet: http://blog.thecodewhisperer.com/blog/categories/integrated-...
The author has several other articles on the subject that I have not read yet, so I'm not sure if I've got a full understanding of his point yet: http://blog.thecodewhisperer.com/blog/categories/integrated-...
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.
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.
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".