Jenk wrote:I personally know of no one who has used B/TDD and went "back." Only experience will show it's benefits.
I do. I don't know anybody who used it properly and went back though

When I first started I was a bit rubbish. I gave up for a month or two and when my next big project started I gave it another go. Although I didn't do a very good job of organising my test code I did see the benefits and got hooked. I think this was the key point -- starting from the start. If you've never TDD'd before, trying to start halfway through a project will just put you off. Mostly because everything that was developed prior to the employment of TDD won't be very test-friendly.
Of course, each project you work on beyond that you get better and better. You get better at:
a) Seeing where you need to have settable dependencies so you can mock them
b) Focusing your tests to one behavioural goal at a time
c) Knowing what NOT to test
d) Writing less fragile tests
e) Setting up the test environment
I think (b) is the most important thing to get the hang of. ~arborint's first example he posted was a good demonstration of where you can trip up. Although this was only for testing a really simple concept, there were tests for two different scenarios/behaviours in the same test method. In a more complex scenario a failing test with multiple behavioural expectations in it would cause confusion. The more methods you have like that the worse if gets.
Writing unit tests very badly often just makes your work load increase since you spend more time maintaining your broken tests than you do maintaining the source code. I can give a classic example of something I fix in other people's tests at work all the time. We have some actual system tests (to supplement our units) which really do connect to a database full of test data. Before each test method runs the DB is wiped and the schema/data is re-imported. A common fragile test scenario I run into with this set up is people making assertions about exact row counts in the test data. Of course, when someone adds their own test data this breaks that test. There are all kinds of things you can do badly which just cause tests to break all the time when the system still works as expected... learning to avoid the situations just comes with practise.