Editorial Note: I originally wrote this post for the Stackify blog. You can check out the original here, at their site. While you’re there, have a look at their tools to help you track down and fix production issues.
A couple of year ago, I wrote a book about unit testing. Now, I didn’t just sit down one day and decide to do it, and no big publisher commissioned me to do it. The book started from humbler origins and grew somewhat organically.
It started as a series of presentations I did for groups new to the practice. With more feedback and requests, it then grew into a blog post series and longer presentations. Eventually, due to even wider demand, I made it into a book.
What was it that made this particular content so appealing, when no shortage of authors address this topic? I feel pretty confident that it was the lead into the topic. “You still don’t know how to unit test, and your secret is safe with me.”
When I started in this industry, only an avant garde fringe wrote automated tests for their code. Over the last 15 years, however, that number has exploded, and the practice has become mainstream. But “mainstream” does not mean “universal.” Plenty of folks still do not have comfort with, or even exposure to the practice. And yet, a form of peer pressure causes them to play that close to the vest.
So I reached out to these folks to say, “hey, no worries. You can learn, and you don’t even have to climb too steep of a hill.” I’d like to revisit that approach again, here, today, and in the form of a blog post.
Let’s get started with unit testing in C#, assuming that you know absolutely nothing about it.