My favourite argument for unit testing comes from <a href="http://www.daedtech.com/intro-to-unit-testing-10-the-business-value-of-unit-tests" rel="nofollow">http://www.daedtech.com/intro-to-unit-testing-10-the-busines...</a>:<p>"Do you think the customer is going to get angry if you explain that part of your development process is to execute the code you just wrote to make sure it doesn’t crash? If the answer to that is “no, of course not, that’s ridiculous” then you also have the answer to whether or not a customer would care if you happened to automate that process."
First step of unit testing is picking the correct language. Static analysis will eliminate the need for whole class of errors. Then apply code contracts. Consider extending your static analysis package of choice to add rules specific to your application. As the last step write unit tests to cover your core business logic - something the computer can't figure out for you. Realizing that unit tests are basically poor man's static analysis is the first step to becoming better at writing them.
If I have projects which were written without tests because I was an idiot and didn't know "running it and seeing that it works" counted as a test, should I go back and write tests for what I already have or start testing on new code only?
Possible counter point: while the unit-tester is busy writing perfect software. I'll be lazy... and perhaps I'll beat them to market and will use the resulting money to perfect the software.