As the comments here show, people tend to come down on unit testing in a binary way (love it or hate it). Like a lot of things in software, especially in software process and double-especially when consultants and authors are involved, it became a religious question. Advocates insist up and down that they love it, it saves time, it's all good. But it's not all good. Unit testing has benefits and it also has costs: you have to write the tests and you have to maintain them. The cost of an entire second codebase is hardly insignificant. So the rational question to be asking is whether the benefits exceed the cost, or rather, when they do.

My experience is that it depends on things like language, environment, and team. I've written many thousands of unit tests in C# and Java and trained quite a few people to write them, too. But when I began working in Common Lisp, I was surprised to find that didn't need them as much. I write and test my code by evaluating expressions in the REPL and I mostly write functional code without side-effects. This turns out to yield many of the benefits of unit testing without many of the costs. The overall tradeoff becomes different, making unit testing less valuable, except in targeted places. Other things that in my experience increase the overall benefit of unit testing include OO designs, larger teams, and corporate environments.

How much I enjoy writing unit tests depends on my gut feeling of whether the benefits are exceeding the costs. If I'm struggling with a tricky algorithm that I want to work out a bunch of examples for, I enjoy writing unit tests very much because they're helping me solve my problem. But if I'm going through the motions of updating a bunch of unit tests that aren't relevant to what I really want to do (and this happens a lot on larger XP projects despite what the advocates say), I don't enjoy it.