It's much easier to arrange for your test code to be extremely modular, with different bits not affecting one another, than it is for the actual application code. And for most problems it's much easier to get evidence that you've solved them right than it is to solve them right. (It's a bit like the difference between P and NP.) Therefore, writing good test code is much much easier than writing good application code. This is the answer to your last question, and the reason why the rest of what you said is wrong.
How do you know your test code is testing what you need it to test without actually testing it? If not by TDD, then are you really using TDD or simply saying that you are?
Like I say. Cut to the chase. Incrementally write good, clean, well designed, application code. Then inspect and manually test. THAT is the ONLY thing that really works. Stop pretending you are doing something that you aren't. Especially don't use it as an excuse for writing lousy, poorly designed, and poorly implemented application code.
TDD is still one more attempt to create a sacred Silver Bullet that gets good results without knowledge, skill, understanding, thought, discipline, or effort. Its at best a very feeble tool in a quiver of feeble tools. It takes a good, well trained brain, paying attention to get good results. Without that, nothing will work.
PS: Writing good code is never easy. It only looks easy when done by someone who really knows what they are doing.
Who here, please, is claiming that TDD gets good results without knowledge, skill, understanding, and all the rest of it? Or that writing good code is easy?
Your infinite-regress argument would be entirely sensible if someone were claiming that all code written without testing it is entirely broken. Fortunately, no one is claiming that. In view of which, what you say is just like this: "How do you know that your reasoning about what the code needs to do is right unless you've checked your reasoning? And then how do you know your checking of your reasoning is correct unless you've checked that? Etc., etc., etc. Therefore, no one is really developing software by thinking about it."
TDD is not supposed to be an alternative to writing good, clean code, inspecting it and testing it. It's supposed to be a way of writing good, clean code. (No, that doesn't mean it's supposed to enable idiots to do that, or supposed to make it effortless.) Maybe it works well -- i.e., enables a person with a given amount of brainpower and a given amount of training and experience to expend a given level of effort and get better code -- and maybe it doesn't; but the objections you've made here don't make any sense.
Sorry. I was attempting to argue with a religion. My bad.
The basic premises cannot be questioned. The words of the sacred order must be followed to the letter. They must be swallowed whole without modification. They are to be held to be applicable to all problems, all contexts, forever, amen. That is except when they don't apply according to some mysterious unwritten set of rules held by the sacred order.
Gad. I can't count the times I have seen this crap since I started developing software back in the mid 1960'sd. It started with designing software using an IBM flow chart template. Each "method" had their very narrow range of applicability. None were the cure all or ultimate solution they were touted to be.
Automated testing has a place. The place is small, narrow, and limited. I seriously question that it can make up for lousy programmers and lousy code. Especially since they are also usually the programmers of the test code.
This is an issue that is indistinguishable from my identified problem of infinite regression. How are you going to test the testers to make sure they are testing what needs to be tested the way it needs to be tested?
Ultimately its do the right things correctly. What that is is much more dependent upon the problem and its context than some sacred text and holy method.
I am not a TDD zealot, nor even a TDD advocate. (I haven't written enough stuff that way to know whether it works well for me, never mind anyone else.) I was just pointing out some flaws in your reasoning. I don't think I'm the one being religious here.
I don't agree with jmathes's diagnosis that you're trolling; I'm sure you really believe that I am a fanatical TDD devotee who thinks TDD is the right thing for every situation, that I regard everything to do with it as sacred and holy, and that I think TDD can make up for lousy programmers and lousy code. Since none of that bears any resemblance to the truth, however, I'm going to leave it here, and just suggest that you go back and re-read what I said, and see whether you can find any actual evidence of zealotry there. Then, when you don't, you might want to work out what's got your zealotry detectors so oversensitive and made you draw such stupid conclusions, and maybe think about fixing whatever it is.
I think your troll detectors are miscalibrated, though not as badly as lgriffith's zealot detectors. But I think you're right that there's not much point in trying to carry on a reasoned discussion with him on this topic. Sorry, all.
