Few days ago, I had to review the code of a colleague that was introducing a new feature on our project. The code was just a few lines of code but it was actually setting up a sensitive feature for our product. During the review I've noticed that it was missing the unit for testing. I've asked the reason for that and the answer was "I've no time for that". Few hours late we've spotted two bugs. The fixing required another hour and then we've decided to write a short unit test.
Testing saves time
The cost of testing doesn't include just the hours spent writing the test itself but it also includes the benefits derived by the time you save to be adequately sure the code is working, minimizing the amount of time for fixing bugs. (regression tests are likely saving more than half of the time of work for a mid/long project)
Tests are goals
Another thing that is usually not considered evaluating unit testing is the psychological impact of it: tests are goals. Passing a test is a prize. In many cases it's also the only gratification you will have from your code. Keep it in mind if you suddenly feel demotivated working on your project.
Prototype Driven Development
Even if I'm a strong supporter of testing I'm not that into TDD (test driven development). I can see the goods of that practice but for most of my tasks I still think is not the best way to go. When I usually have to work on a feature I first split it in small tasks and then I work on them. Usually I start thinking on the solution and whenever something comes to my mind I need to type it as quick as I can. It's just a matter of taste, I love solving problems. I understand perfectly the TDD way might be even better, first analyze the task from the point of view of the effects and the expectations, still I find it less stimulating. I prefer writing tests after.
Never abuse
I also don't like excessive testing, especially at the beginning of a feature. Fresh code is very often volatile and an early refactor will probably make your tests useless and need to be rewritten. My suggestion is to keep your tests generic, following only the main paths and some important edge case. Then the test suite will enrich itself going on: fixing bugs (it is a good practice to write a test to reproduce the bug before fixing it) or after a refactor to cover another relevant path. In my opinion good testing is to find the right tradeoff, you basically need to balance code flexibility, difficulty of the test suite (it can contain bugs too!), writing effort.