I learned how to write test code from one of my first programming mentors. Borrowing techniques used by the Ruby community, he showed me how to use the NUnit test library and Microsoft's Assert library along with Visual Studio's test runner to write code that proved my code worked as expected. This was strange to me at first because it ran counter to my entire programming paradigm.

I learned computer science in school. We were concerned with data structures, compilers, O(n) running times, and algorithms. At my first job, I learned how to debug someone else's code, how to query a database and profile its behavior, and how to get "working" code across the finish line to make my boss happy. The idea that I should write more code than it took to solve the problem seemed curious.

However, my mentor was passionate about this approach to coding. It was the only way "we could sleep at night", content that our code worked how we intended and expected. He took the time to make sure I understood the tools and how to begin thinking about tests around code. I grew to love this way of working because of the confidence it gave me to build software of a quality unmatched by anything I had ever written before.

The computer scientist in me found fascinating the idea that any system could be decomposed into units small enough that their own test code could deterministically prove the behavior and theoretically prevent all bugs of every component. The philosopher in me found enticing the idea that I could ensure quality, readability, and maintainability would be baked into every line of code I wrote. I wanted the next programmer who looked at my code to enjoy the experience.

I carried this new found love of unit testing with me to each new workplace. I taught the passion and associated skill set to whichever colleagues would listen. At my last workplace, I declared myself the Unit Test Evangelist and taught my team everything I knew, and together we improved on the knowledge and skills I brought with me. We had great philosophical discussions on how to think of approaching legacy code with tests, and what kind of tests were the most important to write in various situations.

My last team even included in our Definition of Done that unit testing was an expectation for all code changes and additions. As a result, we saw the number of new defects dive and each time we returned to an island of tested code to make more changes, we were able to make those changes far more quickly and comfortably than in untested areas of the codebase. Even as the team dwindled due to natural turnover, we didn't see a significant drop in velocity, due to the efficiency gains made by our high quality standards.

In my personal experience, this culture of unit testing has always served to improve the product of my team's work, as well as our collective confidence and pride in that work. Do you have a similar experience with a culture of unit testing? What mindset, processes, and techniques do you think are at the root of this success?