Wisdom tells us what we should do, experience tells us what we should never do again
The theory goes that you should write tests to check the functionality of your code, then when you refactor your code or add new features you’ve got a safety net to check that what you’ve done hasn’t broken existing functionality.
The theory is good, but in practice it doesn’t work.*
If you write tests to test your code you won’t write your tests, at least you won’t write all of them and you’ll cut corners. Writing tests to test a piece of code you already have is tedious. You’ll end up compromising your tests. You won’t test the simple stuff, because, well it’s simple, what could go wrong? It may be simple, but that’s just the sort of thing you’ll change without a moments thought but somewhere that’ll have a consequence you didn’t think of. You might skip testing the obvious stuff, but what’s obvious to you isn’t obvious to the next person to look at the code. You won’t test the difficult stuff, because that’s too time consuming and you’ve tested most of the other stuff so you figure you’re fairly safe. You won’t test the stuff that’s ‘impossible’ to test. That safety net that makes you feel secure, the holes are too big – just when you really need it you’ll fall straight through it.
So don’t write tests to test your code, write the tests before you write the code. Write tests to drive the design of your code (TDD/BDD), write tests so you know when you’re done. Only write code to fix a failing test. Yes you’ll still find your tests becoming complicated and stuff that’s difficult or ‘impossible’ to test. Listen to your tests – they are telling you something about your design. And the great thing is at the end of it, a side effect almost, you end with that safety net that really does allow you to refactor or add functionality to your code.
I think TDD/BDD and automated acceptance testing has the potential to significantly change not only how we initially produce a piece of software but also more importantly how it is enhanced and maintained throughout its ‘working life’ and it’s that which is radically going to change the value the software can deliver to the business and so the test become crucial to the success of your business. More on that later.
* when blogging you’re suppose to go for big bold controversial statements aren’t you? 
Although I think your point is very valid, I think some testing is better than no testing. I have seen it be very difficult to change the mindset of seasoned programmers. They just don’t get TDD, and hate testing in general.
Even if testing is done out of order I feel like there is some benefit, mainly that you step through your own logic twice, and have an opportunity to catch errors in your reasoning.
In my experience TDD is much easier in the earlier stages, later on, you end up having to still change both your tests and code when things change.