I'm interested in using a code coverage tool for my next .NET project but was wondering if it is necessary for me? I'm the only developer in the company I work for, so would using NCover be a benefit to me or is it just for large teams using continuous integration? Thanks
+8
A:
I would say go for it. Analyzing code coverage can help even a single developer, maybe even moreso than a team, since you basically have the whole system on your shoulders. If you're the only developer, you have full control over what tools you use, and how you want things setup. Once/if more developers are added, you'll have all the tools in place to create quality software.
Andy White
2009-05-28 04:52:05
+1
A:
Caleb,
In case you don't already know, Visual Studio 2008 Team System Editions of VS2008 can do code coverage for you. It's not as comprehensive as NCover, but it should be a great start for you. If you like what it does and you want more bells and whistles, than I don't see why not. (It's only $200 for the classic edition the last time I checked).
-Artel
Artel
2009-05-28 04:58:43
+1
A:
Of course you should use it. It's always another tool to help you. But remember, code coverage isn't the most important thing when testing your code. You will get a number of lines of code that are covered with tests, but that doesn't mean that your code is bugproof there. Use ncover to find places that have little or no coverage.
ppiotrowicz
2009-05-28 05:00:16
A:
Thanks for the replies! Everything you guys said makes sense. Why not just go for it? It can only help me and further me as a developer. :)
CalebHC
2009-05-28 05:11:01
+2
A:
If go to the effort to write automated tests, then definitely use a code coverage tool to get an idea about how which areas of the code base those test cover.
Viewing code coverage as you write tests is also helpful in ensuring that your tests are actually testing what you think they are.
The overhead of measuring code coverage compared with the overhead of writing tests theses days is so small, that it doesn't make sense to write tests, and then not view the coverage of those tests.
npellow
2009-05-29 05:04:30
Good call. If you already have unit tests, ignoring coverage is pretty silly. I've found that checking code coverage always improves my tests, (since I find out immediately what's being run and fix what isn't) and by extension, the quality of my software. Good coverage isn't a silver bullet, but it does tend to increase your confidence in your tests, and can help focus your testing efforts by avoiding redundant tests and missed corner cases.
Quinn Taylor
2009-06-26 06:46:17