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.

Quote:
“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

Application:
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.

References:
http://msdn.microsoft.com/en-us/library/dd537628.aspx
http://stackoverflow.com/questions/1742323/tdd-vs-unit-testing