Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
This is about .NET libraries (DLLs).
What are the options for measuring code that is covered by unit test cases? Is it actually worth the efforts (measuring the code coverage)? I wonder it might be too easy to cover 70% of code and almost impossible to go beyond 90%.
[EDIT] Another interesting question (put up by ‘E Rolnicki’) is: What is considered a reasonable coverage %?
NCover (both the commercial one and the open source one with the same name) and the code coverage tool in Visual Studio are pretty much your main tools in the MS world.
Code coverage is a reverse metric. It doesn’t really show you what code is adequately tested. Like Nick mentioned, you can have test that cover but don’t really test much. Code coverage instead tells you what area of your code have absolutely no tests. From there, you can decide if it makes sense to write tests for this code.
In general, I think you should do code coverage since it doesn’t take much effort to set up and it at least give you more info about your code than what you had before.
I agree that getting that last fraction of code is probably the toughest and there may be a point where the ROI on it just doesn’t make sense.