I've always tried to make it a point to read a lot about the industry and constantly shifting and improving methods and best practices.  Sometimes the buzz dies down after a bit -- I was particularly amused to find people tired of the lofty promises of EJB and going back to basics with POJO.  Other times it grows to a roar.

The promises of unit testing and refactoring were being extolled for a while, but I must admit it took some time and much reading for it to sink in.  If you're smart enough to make tests to exercise your code cases properly and didn't miss anything, you probably would have handled all those cases properly when you were coding anyway, right?  Perhaps, but what about changing that code 6 months from now?  What about someone else changing that code?  I must admit I find a certain comfortable simplicity in writing unit tests to exercise the boundaries and coverage of a piece of code.  After doing a few, it starts to become automatic and not take as much time as you would think.  It keeps you honest.  Even the best programmers can be burned when making just a quick last minute change that wasn't expected to change another area of code, but invariably does and most people are terrible at methodically manually testing their code countless times.  Too many habits of doing things the same way every time leads very often to surprised cries of "But it worked for me.".  Unit tests also add a margin of comfort to refactoring.  Too often we let bad code persist and create maintenance headaches for years because it's not well suited for automatic or manual testing.

So I'm starting to believe now and writing my unit tests where I can going forward with new code and adding them to existing code when making changes.  As time goes on, existing code will be retrofitted for testing and testing code coverage will increase.  I'm definitely still learning and experimenting on testing methods and will occasionally post snippets or ideas I'm working on.