My intent was not to attack the tutorial, and much less the author, but to take a different position on one point raised by it. As I said in the last paragraph of my post, I like this tutorial and the way it teaches testing as an essential part of programming. Let me add that I think increased and automated testing, performed concurrently with coding, is the best single thing every organization I have worked for could do to improve the reliability of its software.
Nor do I think you are justified in claiming a straw man, as I am not simply saying bad tests are not good, just as the author is not simply saying that, in general, tests are good. The point is that when you are mistaken in exactly what needs to be done by your code, or whether your intended solution fully achieves that, then your passing tests may not show that your code is satisfying its intended purpose, because your tests are written under the same misapprehensions as your code. It may not be possible to show plausible short examples, but the bigger your system gets, the more internal interfaces it has, and the more cross-cutting consistency issues it accrues, the more likely this is to be a problem. This, IMHO, has been one of the hard problems of software development, and one of the reasons why there has not yet been found a silver bullet, TDD notwithstanding.
Nor do I think it is a pedantic point, if you take into account current opinions about how to develop software. The views that I disagree with are not uncommonly seen in articles, books, tutorials and on Stack Overflow, in support of claims for the efficacy of, and necessity for, a strict interpretation of TDD. Again IMHO, this significantly understates the difficulties in writing correct code and avoids considering the problems that contribute most to this difficulty, and a dissenting view has to be raised from time to time.
WRT high-shool debate, I think it has been ruined by rules that scores points made regardless of relevance, coherence or even accuracy, so I hope I am not doing the same thing.
Nor do I think you are justified in claiming a straw man, as I am not simply saying bad tests are not good, just as the author is not simply saying that, in general, tests are good. The point is that when you are mistaken in exactly what needs to be done by your code, or whether your intended solution fully achieves that, then your passing tests may not show that your code is satisfying its intended purpose, because your tests are written under the same misapprehensions as your code. It may not be possible to show plausible short examples, but the bigger your system gets, the more internal interfaces it has, and the more cross-cutting consistency issues it accrues, the more likely this is to be a problem. This, IMHO, has been one of the hard problems of software development, and one of the reasons why there has not yet been found a silver bullet, TDD notwithstanding.
Nor do I think it is a pedantic point, if you take into account current opinions about how to develop software. The views that I disagree with are not uncommonly seen in articles, books, tutorials and on Stack Overflow, in support of claims for the efficacy of, and necessity for, a strict interpretation of TDD. Again IMHO, this significantly understates the difficulties in writing correct code and avoids considering the problems that contribute most to this difficulty, and a dissenting view has to be raised from time to time.
WRT high-shool debate, I think it has been ruined by rules that scores points made regardless of relevance, coherence or even accuracy, so I hope I am not doing the same thing.