Creating code coverage reports with NCover
Sergio Pereira just published a great article on creating code coverage reports with NCover and MSBuild over on devlicious.com. Check it out!
Update From NCover Central Command (or someplace close)
It has been way to long (besides yesterday) since we shared some NCover perspective about where we are headed with the next few versions that we have rattling around in our heads.
Sure, it's going to be cool. Maybe that whole "better than sliced bread thing". But the reality is that it will only get that way with your input and suggestions.
We want feedback...
So light up the conversation pipeline.
Tell us how you are using the platform. We want to know.
- Are you storing your NCover configuration in source control and having your developers pull down these setting?
- Do you have a workflow in place to merge together all testing activity across developer and testing roles?
- Are you using our control filters to divide large amounts of metrics into sizable reporting clusters that can be delivered to different management roles?
- What is your "coolest" NCover innovation yet? Your secret formula for deploying NCover?
Also, tell us what you want in our next versions? We want your feature included.
- Do you want a plug-in to Visual Studio? (Are you planning to upgrade to VS2010?)
- Do you better, faster access to all the data that we are collecting?
- Do you need to deploy and manage enterprise solutions more effectively?
We listen. You don't have to shout (although that could be fun). Just tell us about your dream product.
Quick Tip: NCover Explorer's Command Line
We've had a few users ask about opening coverage files with NCover Explorer from the command line. It's actually as easy as running it with the coverage file as a command line parameter. We also support opening project files on the command line.
So, the next time you're in the command prompt and want to open a coverage file, just run:
> NCover.Explorer Coverage.xmlIntroduction to NCover on Dimecasts
Derik Whittaker at Dimecasts.net recently published a screencast about NCover entitled Introduction to NCover, setting up for analysis. The screencast covers getting started with measuring code coverage for your tests using NCover and NCover Explorer and also dives into satisfactory coverage highlighting and generating reports in NCover Explorer. It's a great basic introduction to using NCover, and Derek says he'll be posting more screencasts about advanced NCover topics in the near future.
Introduction to NCover, setting up for analysis (Dimecasts.net)
We have found the missing Treeview control
Download the new version here.
All's well that ends well, but it wasn't always that way.
Since releasing NCover v3.2.4 we've had a few customers reporting a strange condition where the Treeview control was missing from NCover Explorer and sometimes the trend graph would not render. It was driving me nuts. We tried to reproduce it in the operating system that the customer was using with no luck. Then one day a customer sent a support ticket stating NCover worked fine until they reinstalled the operating system on the machine (XP SP3).
Scratching my head, I installed a brand new copy of XP SP3 and turned off "protect my machine". I then installed .Net 3.5 NON SP1 and poof, NCover was broken.
I thought to myself, 'Cool! Somebody must have updated the build machine to SP1 and that is why it compiled'. This was not the case. The build server was .NET 3.5. I thought, 'Cool, I will just go load up Visual Studio 2008 (non sp1 and no hot fixes) and compile and it should break'. Nope, this did not happen either. I kept thinking I would outsmart this issue and that I must have messed up a check-in or a merge, so I turned on break on all errors, and nothing broke.
At this point I fired up one of my favorite tools, Beyond Compare. I pulled down the v3.1.4 and v3.2.4 branches and ran a diff on both branches. I found this change in the code where one of our developers tried to do the right thing by using a reusable control, a HeaderedContentControl. He moved the style into a resource file and set everything up the way you would expect a good programmer to do. I had a hunch; I asked myself, 'What would happen if I remove the style on the control?' Not really expecting anything to happen because WPF is not HTML, I was amazed to see that the problem went away, the Treeview just showed up out of nowhere.
I had to bring the programmer over to bust his chops for doing the right thing. Who would think that a style would work fine in SP1 but not in the original release of .Net 3.5? After all that research I ended up putting all the code back where it was, making three copies of the style code just to make sure NCover Explorer would work with .Net 3.5 and .Net 3.5 SP1.
Is there a point to all of this? Yes there is: Make sure Vista is not SP2. Since it already contains a newer version of .NET 3.5 SP1 so you will never find the issue. The other point is that even though a service pack is not expected to change the behavior of your application, never assume it won't.
P.S. the complete release notes can be read here.
