I’ve talked to many developers about why Unit Testing (as well as automated integration and acceptance testing) and why I think it should be something that is a natural part of development. I usually get the a few similar responses from those who haven’t adopted this viewpoint.
“I know I should be Unit Testing and that it can be helpful, but …”
I hope to help you get started moving past not knowing how and where to start and make automated testing as normal to you as writing code.
Check out my reorganized version of this article for my presentation with a Github link!
Unit Test vs Integration test 
My first exposure to Unit Testing was in our Software Development class at the University of Minnesota, Morris in 2004. We had A Practical Guide to eXtreme Programming and we committed to paired programming, team roles and Test Driven Development (TDD) in Java with nUnit. I learned a lot about coding and process in that semester and I’m thankful for that experience.
In my first development job after college in 2006, the latest and greatest technology was Microsoft’s WebForms. WebForms was not conducive to unit testing. The code behind and server side events tightly coupled the code and made it hard to write testable code. I also wasn’t surrounded by developers who valued unit testing. During this time, I didn’t see (or realize) the need to write test around my code. We were also creating smaller applications (e-commerce, site content apps) and though we had some quality issues, unit testing didn’t come up as an approach we should take.
In 2008, I first read The Art of Unit Testing by Roy Osherove (thanks to @t3rse for lending it to me). This was eye opening to me. I started applying tests to help myself with MVVM Silverlight applications to keep focused and on the right track.
Later in 2013, I joined a team at a company that decided to invest heavily in automated testing. I was brought in to write automated UI tests with C# and Selenium. We also read Continuous Delivery. Eventually we learned that UI tests are brittle (timing issues with the DOM are the worst) and take a lot of work to maintain. It also started making sense to have developer write the UI tests along with their work. I was then able to move into the regular development cycle. We were using KnockoutJs which enabled the MVVM pattern in our TypeScript client code. Jasmine testing also was decided on by the team and the number of tests slowly grew (now it’s normal and expected). Near the end of 2017, we have 4754 tests and counting. Our team is using Git and Pull Requests to help with code reviews and ensuring quality. Once a PR (requiring fast tests to pass) is complete, it is merged into master and the builds do their work. Each PR is a release candidate that could be released if all tests pass. We’re able to move quite quickly while limiting the amount of manual testing that is needed.
My recent Tweet:
Follow the Testing Pyramid. Unit tests are the foundation and the fastest feedback for developers. Then integration and finally UI Automation tests. Flipping that over (the ice cream anti-pattern) will cause a lot of difficulties. You’ll find yourself trying to reduce the UI tests after the test fails on a timing issue for the 10th time.
Manual exploration testing is still very important. QA minded engineers know how to break things. Talk to them (and business people) before starting to code to help define specifications with examples 
There are many reasons, discussions, books and articles. I’ll highlight a few that I think are important.
Senior developers’ experience “If you’ve never tried test driven dev, you’re missing out. Even after years, watching a test go from red to green is immensely satisfying.” Cory House on Twitter.
Can’t do CD or DevOps practices without it.
As we noted above, the hardest part of changing processes and approach to programming is knowing where to start.
There are many possible places:
Word of caution: Expect to spend a lot of time adding in your first tests in existing code that wasn’t written with testing in mind. It takes refactoring and a lot of work to add in the proper testing seams for faking. It also takes practice and time to write good tests.
The best way to learn something is to start doing it and practice.
I’m working on a Part 2 which will have examples in C#, Asp.Net MVC Core and with TypeScript code. Hopefully, I’ll have this up early 2018.
Kent Beck in TDD  makes a list of things that need to be done and works through the red, green, refactor loop while crossing things off the list. I found this to be a great idea (it works well for debugging tough issues too).
 Osherove, Roy. The Art of Unit Testing Second Edition. Manning 2014
 Andrew Hunt and David Thomas. The Pragmatic Programmer. Addison-Wesley 2000
 Gojko Adzic. Specification by Example: How Successful Teams Deliver the Right Software. Manning Publications June 6, 2011
 Downloaded from https://media.giphy.com/media/l0MYSpvx4pnsoMNz2/giphy.gif, seen on https://hup.hu/node/149706 October 12, 2017
 Gene Kim, Jez Humble, Patrick Debois and John Willis. The DevOps Handbook IT Revolution 2017
 Kent Beck, Test Driven Development: By Example, Addison-Wesley Professional; 1 edition (November 18, 2002) * https://www.amazon.com/Test-Driven-Development-Kent-Beck/dp/0321146530
“A National Institute of Standards and Technology study found that it costs twice as much to make minor enhancements to a system than it cost to build the system in the first place.” “Why is it so expensive to add features to existing software? In a nutshell, it’s because we don’t value writing changeable code, or we think that writing changeable code will take much longer to write. “
I’m using this material for South Dakota Code Camp 2018. The link will only work until the next code camp ;-).
Please consider using Brave and adding me to your payment ledger. Then you won't have to see ads!