Testing by Coverage

time to read 2 min | 332 words

I'm going over NQA's test coverage right now. I added tests to some areas that desperately needed tests, and several code paths that weren't tested. The best parts were that I found pieces of dead code that I could just remove. As usual, ReSharper is invaluable in finding those parts.

I'm partly dog-fooding Rhino Mocks, and I got some interesting ideas for improvement, and partly to actually get a better code coverage on NQA :-) [I just thought that I've found a bug in NQA, but it was in my tests.]

I didn't have much chance to touch certain parts of the code, specifically, the SchemaEditing parts, and going over the tests is a great way to reacquaint myself with what is going on there. 

On the other hand, it's kind of depressing, I look over the list, and there is so much red there... :-( I'm currently reading Working Effectively With Legacy Code right now, and the definition there is "Legacy Code is code without tests."  On the third hand*, the book offer good advice about how to handle that. I wish I would've read it five months ago, I would've made a lot of different choices in how to bring NQA to the Fun-To-Work-With world.

I've finished reading  Extreme Programming Explained : Embrace Change (2nd Edition), and I'm not sure what to think. On one hand, it's the first book that actually made me put it down and reach for the code. On the other hand, it seems that it's not quite an introductory text but more of a guide. It wasn't what I expected, that is certain. I think I'll need to re-read that (which I don't usually do for tech books) to really grok what Kent is trying to say.

* It's pretty handy when juggling, too. :-)