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.
I was moved to work with a different company in the summer of 2018. The(building on top of 30 years of systems) project that is now several years old without tests, lacking separation of concerns in the code and loads of regression issues has been a challenge. - I had a lot of FDD (Fear Driven Development) after changing some things and breaking other things - The company wanted to have automated tests, but deadlines drove them not to do them - Regression bugs are most of the work we’ve been doing in the last months. We often hear, “this used to work” or “we fixed this a few months ago” - A unit testing committee was formed to get tests going and educate. The Art of Unit Testing book club was done together and we are starting to hear stories how the tests stopped a regression issue. - in the summer of 2019, we only have 12% coverage (in our part of the system), but that’s increasing and new code is mostly getting covered - people are mentioning it more in Code reviews and adding them before getting asked to more and more
It's never to late to automate #unittesting— Kevin Logan (@alignedDev) June 12, 2019
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).
I took an informal survey and here are some good things to look for in unit tests.
DevOps Journey from Microsoft. “Automation is key — Automation should be considered and pursued across all areas of the software lifecycle, especially if the organization is planning on making changes to roles and accountabilities. Manual efforts, especially in the spaces of testing, environment creation, and release management, can significantly delay delivering value to customers.”
Art of Unit Testing book – Roy Osherove - start here
The Phoenix Project book – DevOps story by Gene Kim
Test Driven Development book – Kent Beck
Accelerate DevOps book – Nicole Forsgren, Jez Humble, Gene Kim
Microsoft Virtual Academy – TDD - https://mva.microsoft.com/en-us/training-courses/testdriven-development-16458?l=iCWHq6vXC_2706218965
The bowling Kata section is eye opening
Clean Code book - Robert Martin
Specification By Example book – Gojko Adzic
Add a TODO and don’t start “shaving a yak“
 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!