I actually enjoy writing unit tests _because_ I'm lazy :).
When I write a piece of Ruby code, I have a choice: I could either write a unit test or load the code into IRB and manually test it (or even load the real app and test the code in there).
For me, doing it manually is often more work. Let's say I have five tests in my head. My code passes the first four, but fails the fifth. After I fix the bug I found, I have to manually go back and test all five behaviors again. Unfortunately, my code often has more than one bug, so this process can take awhile. Once my code passes the tests, I always run the real app to make sure there are no bugs in my tests.
Plus, for me, writing code is just more fun than doing tedious manual testing, even if it takes a little longer initially.
As with everything, there are exceptions. If I'm fixing bugs, I tend to have a TDD approach, but if I'm doing exploratory programming, I tend to not write tests until the code is pretty stable. It's also hard to unit test GUI code, so think about the expected return on your time investment.
One thing to keep in mind: tests are more fun to write (and more importantly, more effective) as you get better at them. Writing tests is an art unto itself - just because you write good production code doesn't mean you'll instantly write great test code. It takes practice.
I sometimes hear people say, "Unit testing takes too time to write and maintain!" While there will always be some costs, I've found that as I've gotten better at writing tests, those costs have gone way down, while the benefit has gone up.
When I write a piece of Ruby code, I have a choice: I could either write a unit test or load the code into IRB and manually test it (or even load the real app and test the code in there).
For me, doing it manually is often more work. Let's say I have five tests in my head. My code passes the first four, but fails the fifth. After I fix the bug I found, I have to manually go back and test all five behaviors again. Unfortunately, my code often has more than one bug, so this process can take awhile. Once my code passes the tests, I always run the real app to make sure there are no bugs in my tests.
Plus, for me, writing code is just more fun than doing tedious manual testing, even if it takes a little longer initially.
As with everything, there are exceptions. If I'm fixing bugs, I tend to have a TDD approach, but if I'm doing exploratory programming, I tend to not write tests until the code is pretty stable. It's also hard to unit test GUI code, so think about the expected return on your time investment.
One thing to keep in mind: tests are more fun to write (and more importantly, more effective) as you get better at them. Writing tests is an art unto itself - just because you write good production code doesn't mean you'll instantly write great test code. It takes practice.
I sometimes hear people say, "Unit testing takes too time to write and maintain!" While there will always be some costs, I've found that as I've gotten better at writing tests, those costs have gone way down, while the benefit has gone up.