Most of the stuff I write here is code-heavy. I typically set out with a specific goal that I want the reader to accomplish by reading my articles, and most of the time, the posts I write take on a “how to” sort of format. I’m going to change things up a little today and focus more on the big picture with respect to unit testing. I think most coders out there have been preached to about the benefits of unit testing and how important it is, and I suppose this article is just another version of that.

So what is unit testing, exactly? Unit testing is writing code to test your code. It involves writing (or receiving) a test case in non-code which describes the input and the expected output for a small portion of a codebase. Once the test case is well understood, the coder can then build the test around it. A test is run using what’s called a “test runner”, unsurprisingly, which indicates the result of a test or group of tests (almost always “pass” or “fail”). A failed test will typically have a reason for the failure (for example, “expected 4, but got 5″) along with a stack trace. There are many, many different ways of writing unit tests, with many different libraries to make it easier, but the reasons for doing it are the same. Here’s six reasons why you should be unit testing your code, in no particular order.