Writing unit tests is the right thing to do to provide regression testing and just provide some proof that things work how they should. They are the safety net that make sure that when you change the facing on the capstone that the rest of the arch won't collapse.
That being said, one does not always get the opportunity to invest the time it takes to get past that big learning curve to make it part of the daily toolbelt. But knowing unit testing will help in the long term, you get the itch to add them after the fact.
The problem is that they're much harder to just tack on as methods aren't guaranteed to be truly granular in their purpose. Methods and classes tend to be responsible for too much. So how can you write tests to cover all of the responsibilities?
The simplest answer is to write to what you know. I know that Method FastCash() logs into my bank account and withdraws $60. So I write a unit test to check a good login, bad login, pad pin number, scenario where I have $60 to withdraw, and a scenario where I'd be overdrawn. Seems like a decent bunch of simple tests for the FastCash() method, right?
Well, by using
NCover, you can run coverage reports on your unit tests. When I do this, I discover i'm only hitting 67% of the logic of the FastCash method. As it turns out, there's a third bit of functionality in there -- automatically, it assumes you choose the Checking account. NCover shows you the lines that are not getting hit by your unit tests, and allows you to specifically target those additional scenarios you weren't truly testing.
I was able to put this into good use today while finding some pure business logic classes. That makes it much more simple to write unit tests for as there are minimal dependancies and coupling occasional, and a great opportunity for well defined acceptance criteria. Both make it that area of code a natural fit for unit testing.