Motivation is an important factor when learning something new. It is what makes you ambitious and what helps you forget the effort that needs to be invested. If this motivation is missing then you'll have a really hard time and usually give up quite soon.
I guess that is also one of the major problems in getting people into automated testing and unit testing more specifically. They miss the motivation because they don't really see the benefit they get. Instead, they will point to the additional "work" of writing the tests and they might quickly go into the direction of telling you "well, you know, we're quite under pressure in getting things to work because we're approaching the deadline and the customer..."
because a good programmer may be quite a bit faster in "getting things to work" visibly than you'd be when coding in a test-driven manner. However this is just partially true and that's also why I put the quotes. "Getting things to work" and getting things to work may differ towards the end of development
Take this metaphor which came into my mind today when leaving work for lunch. It doesn't fully cover test-driven vs. plain old programming, but I like the concept on how it captures the argument of development speed:
Do you know these nice electric bicycles? They're currently the big hit in our town here.
And you know what? Automated testing can somehow be seen as such a nice electric bicycle while a non-test-driven developer can be compared with a person using a normal, plain old bike (and that's fine btw).
So, if you're a sporty person, you might quickly start and drive me (a TDD dev) away because these electric bikes have some kind of dynamo mechanism build in, which makes it more difficult to get speed initially. But once I get going, I will quickly recover and probably even overtake you. Of course you'll reach the end, the question is when and how much you're sweating ;).
I think you get the idea, don't you? Using test-driven development may need a bit more effort during development, especially if you're not accustomed to it. But once you get more expertise and once you're in the test-driven flow
you get faster. Change (in the requirements, due to refactoring and so on) can be accepted much more easy and bugfixing will be much less stressful mainly because you don't need to fear about breaking existing code. There's much more peace involved. That's also why I'm sweating less ;)
Questions? Thoughts? Hit me up on Twitter