Using automated unit tests to differentiate your code

My personal experience with writing white box automated unit tests covers most of the below benefits. Needless to say, I can't get enough of them :)

• Repeated and quick execution (the more frequent you run them, the faster your feedback loop). Helps in early detection (and fixing) of bugs
• No fear of code merge issues
• No last minute surprises
• Real regression...not smoke. Assumption is that you have more than 80% test code coverage for all key classes
• Less dependence on specific people as it is easier to see programmer intent by studying the tests along with the code. Serves as technical documentation for your code
• Higher quality as most often the source of bugs is unreadable or complex code. Unit tests allow you to refactor safely and quickly, hence keeping code readable and organized
• Best way to prepare to pay off technical debt
• Motivational! Programmers feel happy about their workday due to passing tests … hey, at-least something is working!! Its like gamification of programming
• Automatically document the design / architecture
• Quick debugging (studies show that 80% time is spent in locating the bug), if you have good unit tests you use the debugger less because your tests help you identify possible problems with your recently written code
• If you use tests as technical documentation, then you don't have to worry about keeping your documentation current. Needless to say that good tests (with good test naming) work better than bad tests
• Very effective if you follow the 80-20 rule. Choose carefully what you want to unit test first (in a code base that was not test driven from the start)
• If you want stability (less bugs), then write tests for those modules which are the source of most recent bugs. In fact it is very desirable that you first reproduce the bug through the unit test and then fix the bug. This will ensure that the particular bug never comes again as their will be unit test in place to check for it every time. Remember, your client's confidence is shaken every time a bug reopens.
• If you want higher productivity, then write tests for those modules which have more frequent code changes/commits
• It promotes good design and separation of concerns
• It improves quality and reduces bugs
• It speeds the overall development process as you can quickly experiment and then run your tests every 15-30 minutes. If a lot of tests start to fail unexpectedly, you might choose to just rollback the work done in last 30 minutes and start fresh
• Helps developer get out of coder’s block (just like writer’s block), allows you to safely experiment and poke around the problem
• Helps you stay away from forking your code. You can quickly expand your feature set and not worry about manual regression testing for the new client. Usually people fork their code when they have to ship for a new client and don't have the time to build those new client specific features and test on the whole application.

Best way to start with unit test writing is to follow James Shore's famous YouTube series: https://www.youtube.com/watch?v=F534zh9rsaA