Coding Practice: How much code should I expect to cover with my unit tests?
This is another one of those questions where the answer is “it depends”. A hard fast rule of thumb is that you should strive for 80% code coverage. The goal is to make sure that all relevant functionality is covered by a unit test, or said another way, your business logic should be as close to 100% covered as possible. It is understandable that you will run into external dependencies that you just can’t reasonably reach with your unit tests, thus why 80% code coverage is the accepted rule of thumb.
“We recently started a new small project and a small portion of the team used TDD, the rest wrote unit tests after the code. After we wrapped up the coding portion of the project, those writing unit tests after the code were surprised to see the TDD coders already done and with more solid code.”
– Walter on Stackoverflow
Finding out what percentage of your code is covered is as easy as clicking Test > Analyze Code Coverage in VS 2012. After you run that, your attention should be drawn to the code that is not currently covered by a test. It is not uncommon to discover exception scenarios that are not being covered by your tests, and you can use the detailed information provided by VS 2012 to help you create missing unit tests and address potential issues that could impact quality.