coverting XML to a class

I was working on writing some enhancements to my coverage.xml file that was generated from ncover (more on that on a future post). I wanted to avoid trying to use the .net XML classes like XmlDocument, mostly because the syntax is cumbersome . I’ve serialized and deserialized xml objects before, but I was thinking it would be awesome if I could generate a C# class just from my coverage.xml file.

I was trying to find out if someone had built something like that already. After looking around the web, and not finding anything promising, I finally I asked the .net oracle: James. Apparently what I needed was already in .net: xsd.exe. The syntax for what I needed to do was super easy:

This generated an coverage.xsd file:
xsd coverage.xml

And this generated my coverage class:
xsd coverage.xsd -c

 

html gems

Gotta love these little gems when you find them. Found this one, did a quick search and found these peppered throughout my project. I don’t have to heart to explain to the developer who wrote this why they are an idiot.

<td colspan=”1″>

code coverage

I was recently talking to another developer who was going through the process of setting up cruise control. They already had some tests, but wasn’t sure about this thing called ‘code coverage‘, what was it? And how do you use it.

Code coverage, watered down, is a metric to measure what lines of code your tests are covering. On my current project we user ncover. Should you use coverage to evaluate the quality of your tests? Absolutely. Its so easy to hook up to to an existing unit testing framework, there really isn’t an excuse not to be using it.

Next question: What is a desirable coverage? 100% coverage would be awesome, but it extremely difficult to test every single line of code. My current project, our goal is 90% coverage. There are some more rules of thumb I like to follow. Every function should have at least one test on it, and you should only be done testing a function when your functions coverage is above 90%. Also if you are at 90% coverage and you have a 4o lines of untested code, then you need to write more tests.

When evaluating coverage, I’ve been looking at a metric I call ‘Average hits per line’, lets say I have a 20 line function that is hitting 17 lines of code. Before I decide to try and go after another 3 lines of code, I’ll look at the ‘Average hits per line’. It its above something reasonable, like say 4 average hits per line, then you probably could spending your time better working on something else.

To close I’ll talk about my current project. Sadly with my above lecturing, this is a pie in the sky on my current project, in my defense we’ve had probably 20 developers role through our project who had their own agenda’s and ideas on testing, and coverage. My current project has 3 main tiers, 31334 lines of code, and 2393 unit tests. Our total coverage is 85%, 2 of our 3 tiers meet the 90% coverage goal. DataAccess = 97%, ServiceAgents = 92%, BuisnessLogic 78%.