Learning Unit Testing VI - Code Coverage

by paet the pagan-gerbil 30. November 2010 13:18

Before I get into finally finishing off that blasted page 10, I thought I’d go through a code coverage run to see how I was doing. Test Driven Development, see, everything should be covered by a test.

image

7.41% of the code is not covered by tests! I must be doing this wrong...

image

Phew, that was a relief. Turns out all of that uncovered code is in the WrongPhaseException I created from the Exception snippit without thinking about it. Activating the code coverage colouring in the code shows me what I’ve missed:

image

Because I only use one constructor out of a possible four, it counts as only 25% coverage and brings my average code coverage way down.

If I was to remove all those extra constructors (and leave them to the default Exception behaviour), would it improve my code coverage score?

image

Absolutely. It might be a bit like cheating (those methods are still not covered by tests), but since they’re core parts of the framework it doesn’t feel necessary to me. Short and sweet, on to part VII!

This is a learning project I am documenting in order to teach myself TDD and unit testing – as I publish this, I have already written many parts in advance but I want to know what I’m doing wrong! If you see improvements or corrections, either to the code or the process, please leave a comment and let me know! Introduction to this project can be found here.

Tags: , , ,

Programming

Comments

12/23/2010 9:43:41 AM #

David

I think removing the constructors created by the code generator is the way forward! Bear in mind you will still have a default public parameterless constructor, even if it's not explicitly implemented. To hide the default constructor, you can mark it as private.

I suppose you also need to think about whether you need the (string message) constructor, or the (string message, Exception innerException) constructor. Is the WrongPhaseException a wrapper for a framework exception (in which case use the innerException constructor), or is it used to highlight a particular logical problem in the code?

David United Kingdom

12/26/2010 4:19:42 PM #

Pete

It's a particular logical problem - nothing to do with framework exceptions at all. I think I hid all the generated constructors in the end, but it was interesting that although they exist, only the 'explicit' code counts when calculating code coverage.

I should really post some more of these if you've gotten to the end already! I've got a good chunk more written up on another machine... but taking a break for Christmas!

Pete United Kingdom

1/5/2011 3:02:29 PM #

David

Ah, I haven't been very methodical I'm afraid. The only ones I've read are the ones I've commented on. I do find your code quite easy to read, which is a good sign I think...

David United Kingdom

Add comment


(Will show your Gravatar icon)

  Country flag

biuquote
  • Comment
  • Preview
Loading




Powered by BlogEngine.NET 1.6.0.0
Theme by Pete Fullergreen, based on one by Mads Kristensen

Calendar

<<  May 2012  >>
MoTuWeThFrSaSu
30123456
78910111213
14151617181920
21222324252627
28293031123
45678910

View posts in large calendar
Shop at Amazon.co.uk