Finally the light has come on with me and TDD. I totally get-it from a process perspective. I totally get-it from a qualitative perspective. And as a software engineer, I am innately averse to fear-based coding. To be perfectly honest I'm not entirely there either. I've fiddled with TDD - in so far as most of us have. Exploring the novelty of writing a test, running it to failure and then coding it to success. There were/are several issues, but the one that was second on the list is best expressed: "so what, I have a lot of tests"
Well, due to some prodding by my adopted boss and some ribbing from a fellow blogger (Jonk), I've started to find TDD actionable. I've "seen the light" all along, but how to make it real was always the problem. The other day I wrote a method called CityStateZip() on an Address class. You get the picture, you always want that pretty one line of the address for display but constantly doing the string.Format() gets really old. Yes I am aware that some of you out there just realized that in your mind I 'adulterated' a business object with display logic. All I have to say it bite me. It's a standard format, standard to the domain of Addresses in general. So dismount your separation of concerns high horse and lets move on. Proud of myself (um, yeah) I checked it all in and went about my business (What no code review? Bite Me). The next day my adopted boss, let's call him Tony, said, "Hey, you guys gotta watch those tests. You checked in a method CityStateZip and didn't add a test for it."
Well Damn. He got me. I had been thinking about looking into a code coverage tool to give us an indication of how much of our code was covered by our Unit Tests. We had been doing a modest amount of them....
I'm trying to avoid another aside for you whiners out there who are wondering why my boss was watching the code check-in by check-in, but let's just deal with it. - Get over it. It's code and odds are half, if not more of it should be thrown away and done again, but you're not going to do that cause it's too painful. So get excited that people who don't know what you were thinking are reading the stuff. I'm probably going to programmer hell for saying this, but I'm not a big fan of giant code review as a process (caveat: I don't write code for medical devices). I'm in favor of peer driven - show and tell and frequent check-ins. Small changes are easy to follow and easy to address. Check in frequently! We have setup a set of speakers and CCTray such that when a successful build goes through we all hear it. And when it breaks, the same. Most reward is when you fix the build. So checking in is a bit of a game and the sounds satisfy something deep in the lizard-brain portion of every software engineers mind. No hiding, no fear.
Where were we? oh, yes... Code coverage. Accelerating to make my go home from work time box. I checked out NCover; liked what I saw enough to download and install it. Loved it even further when I saw that it easily (well with a learning curve for me) integrated with MSBuild. Some futzing and time later I had incorporated it into my "continuous.build' file that we use to kick off our automated build process. Some more futzing and I had it plugged into the new build server. It's important that it's the "new" server because after I trumpeted my new found love for NCover, Jonk informed me that we'd had that on the old server over a year and a half ago. So, like usual, I'm behind and he's ahead. I was looking for him to ask about code cover tools anyhow... Would have saved me a bunch of time... Jonk you're officially on speed dial.
So, NCover is just plain goodness. Look-in coverage on the code with metrics about how much of it is covered by Unit Tests. At the end of last night when I left work we were at 35% coverage. Today, by the end of the day we're at 69.9%. Granted it's a brand new product so getting coverage is easy, but this when you should worry about this stuff right?
This is where it gets good. After an afternoon of writing unit tests to get our coverage up (*.Domain.dll @ 100%) I have both more experience writing unit tests. Something I dreadfully need. Franky, it's a whole different skill. And I get a lizard-brain reward (the most satisfying kind) for my efforts. I have nice green bars and %'s around the coverage. Better yet, the Cruise Control integration means that every time a build runs, we get new numbers... And... wait for it, waaaiit for it... The build can fail if the coverage numbers (either on one assembly or the aggregate) drop below the minimum specified. This adds a whole new dimension to the check-in game. No tests, no Mario. No Mario, no dopamine for the lizard-brain. It also has created visibility around tests and as the wise man once said, "if it's visible I can see it." Then as the not-so-wise man observed, "if I can see it, then I have to deal with it". I'm not sure but I think I just encapsulated a major portion of the agile process (sorry agile consultant people). So by bringing test coverage into the light we now have a new rubric for measuring the success of every check-in and fear that we'll upset the automated build beast. All in, I have yet to get to the place where I instinctively write tests first, but I have to write them anyhow now, so it might as well be first. Think there might be a faint glow in the TDD light-bulb above my head. So give it a try, complete the feedback loop and remember to love your lizard (but in an appropriate setting)
Tony, thanks for quipping. Jonk, thanks for leading me to the water. And to all a good night