Re:Integrated Tests Are A Scam
by jmcgough on Saturday January 04, 2014 @12:09AM
(#7010036)
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".
Re:Integrated Tests Are A Scam
by phiggy on Saturday January 04, 2014 @04:30PM
(#7013033)
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".
Re:Integrated Tests Are A Scam
by pmiller2 on Friday January 03, 2014 @10:48PM
(#7009889)
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.
Re:Integrated Tests Are A Scam
by phiggy on Saturday January 04, 2014 @04:34PM
(#7013045)
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.
Re:Integrated Tests Are A Scam
by Jayschwa on Saturday January 04, 2014 @01:43AM
(#7010274)
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.
Re:Integrated Tests Are A Scam
by aaron695 on Saturday January 04, 2014 @02:50AM
(#7010405)
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.
Re:Integrated Tests Are A Scam
by muhuk on Friday January 03, 2014 @10:02PM
(#7009787)
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.
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".
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-...
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
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-...
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.