I think you might be causing some confusion with the terminology you're using. When people speak of testing code, more and more they mean in an automated fashion. In other words, test suites that exercise all of the code for you, and check for expected results. There's a difference between that and trying out the program in an ad-hoc way after you make changes. Sure, both can be said to be testing the code, but generally the automated test suite variety is what people call "testing."

If your post is about testing as in writing test suites, then I think the implication in your post -- that "testing" is a crutch -- is wrong. As others have already written, any non trivial piece of code will tend to have some bugs, and anything you can do to find those bugs is helpful. Furthermore, a good test suite can help ensure changes to one part of the code don't cause problems in other parts of the code. I definitely think test suites help with those things, so I think they're useful tools.

If, on the other hand, you meant trying to go through the program after each change, then it's not so clear. Certainly, you will tend to "smoke out" new bugs, but only if you do the right sequence of events. It could end up giving a false sense of security when things appear to go right. On the balance, though, I think it's worthwhile.

So I guess my point is that whichever type of testing you were talking about, it is useful. Writing a lot of code all at once may be fun, and if it works on the first try, very satisfying. But my experience says that's not a very common occurance, and it's probably best to try the code as it's being written, so problems can be fixed as they're created.