If
Scott Hanselman lives and die's by unit tests, why don't we all just fall in line? It seems the nerd community, has an uncanny ability to adopt silly things quickly. Things like
xkcd.com or the idea of ninja's. I have yet to laugh at one xkcd or understand how ninja's are relative in any shape or form, because of this I felt I needed to read up on unit tests, specifically for C#, to find out if it's just hype or this is something development shops with a strong QA team really need to look at.
I read two books that covered the topic of unit testing. The first book was
Foundations of Programming (recommended by Scottie H. himself and is free) and the second is
Pragmatic Unit Testing In C# with NUnit. Both of them start off with the same old song and dance on how you might have up front costs of introducing unit tests to your code, but the stability these tests provide over the duration of your codes lifetime will cause such dramatic cost savings for the company, it would be foolish not to explore the idea. What a compelling sales pitch, a pitch salesmen, for just about any technology, have used since the beginning of technology in businesses. I'll cut all the used car salesman tactics out and state the most intriguing argument to unit test. It increases code stability and it's easy.
The next question I asked myself: What do I exactly test in the code-base I am working on? In Pragmatic Unit Testing (PUT) they give us an acronym to use in order to answer this question. BICEP.
BICEP, breaks down as such.
Boundary Tests
Inversion Tests
Cross Check Tests
Error Tests
Performance Tests
These are the 5 major aspects one should test, according to PUT and it provides unit testers with a place to start. The next major topic in discussing how to test code is decoupling one piece of code to another. Does your code talk to a middleware? How do you test if middleware is not done creating your service to consume or if middleware is down? In steps
NUnit Mocks,
NMock2, and
DotNetMock. These 3 mock frameworks provide the developer with the ability to feed your tests predefined values, values decided by you. Without going into how to use these mock frameworks, I believe that outside of a few isolated situations they should not be used. The entire purpose of testing your code is to test that you are getting information back that fits the criteria you are looking for. If this information, that is beyond your control, changes on whatever level for whatever reason, you as a developer need to know. Putting in mock objects hides this.
Since I work for a web shop, the topic of web UI unit tests interested me. PUT recommend using
Selenium. This makes sense because it still uses the nunit style of testing keeping all your tests to one testing style. Selenium seems a bit cumbersome in comparison to
WaitN or
iMacro, but I feel keeping all your testing in the same style outweighs the cons of not using Selenium. The more desperate testing sources you introduce, the more confusing it is for an outsider to step in and see the whole picture when learning the code, especially when it's not contained in a single
solution.
Finally, I recommend reading both of the books mentioned, but lets be honest most of us care so little about unit testing we'll be lucky to read all of 1 of these books let alone all of both. If this is the case I recommend PUT, while the first few chapters read like the high school teacher striving to gain his students social acceptance, it's an easy read and you can jump into the book at nearly any chapter and get the exact information you are looking for on unit testing. This is something I wish all programming books could achieve.