Monthly Archives: July 2015

I love TDD. I speak a lot about TDD. During these talks I tend to field a lot of questions. Occasionally someone will say “I’m just not sold on TDD” which isn’t really a question, but begs a response.

For many TDD evangelists, the response to this is to launch into a monologue of all the reasons why TDD is great and why you should use it and all the scary stuff that will happen to you (… up to and including death!) if you don’t use TDD.

This is the wrong approach to bring someone around to TDD. If they are at this point where they can say they aren’t “sold” on the idea, they probably have already heard the speech about TDD before. It didn’t move them then, why should it move them now?

That doesn’t mean that it shouldn’t be addressed. But the first thing to figure out is why someone isn’t sold on TDD. So that’s what I’m doing. Now.

I’ll be working on a series of posts that (I hope) will help people see the light and drink the TDD Kool-Aid. But first I want to know what is keep you from loving TDD. Is it the process? Is it the learning curve? Is it the tooling? Help me help you.

Leave your reason in the comments below, or tweet them to me. I’ll address as many as I can in future posts.

You probably know one of the most common cliche lines someone will say during a break up is “It’s not you, it’s me.” Well, this time it’s definitely not ME. It’s YOU. More specifically it’s your business card.

I go to a lot of software development conferences, user group meetings and meet ups and I’ve collected hundreds of business cards. Many are very straight forward; name, title and contact information. Several years ago it was trendy to create an “interesting” business card. Sometimes this was a funny or interesting picture or phrase. Sometimes is was a curious bit of personal information about the person who gave you the card. On occasion is was even weird shapes or sizes.

One of the trends was the off-beat title. It wasn’t good enough to be just a “developer” or a “consultant” anymore. People had to have crazy titles that, it seemed, were more intended to get a laugh than to convey useful information.

I’m not saying the colorful titles are a bad thing. When done well they can certainly differentiate you from the rest of the herd. They can convey a feeling of passion beyond just slinging code. A well crafted title can make you memorable.

But here’s the key; your off-beat, colorful invented title still has to convey to me what you do. When this trend first started I would see titles like “Software Craftsman”, “Bit Herder” or even the occasional “JavaScript Ninja.” I like these. Maybe they are clever, maybe not. But they still convey to me some notion of what it is you actually do.

What. The. Hell?

Lately I’ve started to see a lot more titles like “Web Visionary” and “Awesomeness Instigator” and even a “Thinker in Residence.” I also seem to meet a lot of “Whisperers” who ironically always seem to be the loudest people in the room.

OK, other than screaming that you are likely a giant douche-bag, these titles don’t tell me anything about you or what you do. Well, that’s not quite true; they tell me that you spend WAY too much time trying to think of clever things to call yourself. Not particularly helpful to me.

By the way, the “X Whisperer” thing was played out two years ago. Can we finally make that go away? And can it take “Keep Calm and X On” with it? Can these be done please?

After a conference when I can no longer put a face to a name I need your business card to help me remember you and what you do. If your card says you are the “Chief Donut Consumer at WatchingPaintDry.com” odds are I’m not going to remember what you actually do, what your skill set is or why I should even care. I’m also unlikely to take time to go to your website and try to figure this out. I’m a very busy man, and, well, Arkham Knight isn’t going to play itself now is it?

The Takeaway

I’m not saying “zany” business cards or interesting titles are bad. The truth is that a well-crafted one will stand out and keep my attention. Heck, it may even get me to follow that person on Twitter. But we need to remember that the purpose of the business card is to be your proxy when you’re gone and the person you gave it to is trying to remember who you are, what you do and why they should care. I’ll take a boring informative card over a clever card that tells me nothing anytime. If you can combine the two, then you’ve got something!

I love TDD. I practice it in my “day-to-day” developer life. I’ve written a book about it and speak about it and conferences everywhere I can. I even did a 30-post series on it for a previous employer. So I tend to get involved in a lot of discussion about TDD, BDD, ATDD and many of the concepts, practices and tools surrounding them. One topic that is paradoxically my most and least favorite is Code Coverage.

For those who may be unfamiliar with Code Coverage, allow me to explain. Developers write unit test that exercise code. These test are run and they either pass or fail. Code Coverage is the process of analyzing those test runs and determining which lines of non-test code are exercised (or run) by the tests. The data collected is generally viewed in two ways; which specific lines of code were exercised by a test and which were not (more on that later) and the percentage of the code base the was exercised.

Death by Numbers

Of the two pieces of data generated by code coverage, management tends to latch onto the percentage of the code base covered as a means of evaluating the effectiveness of the development teams testing efforts. This makes sense. Most managers are trained to work with numbers, manage several teams (making looking at actual lines covered impractical) and in some cases aren’t technical. In these cases, when analyzed correctly, the percentage can be a good metric to track.

The catch is the whole “when analyzed correctly” part. To the uneducated, 100% code coverage sounds like a great goal. The problem is that very little though is put into how that number is arrived at by the code coverage tool.

When Is Your Code Not Your Code?

If you’re a .NET developer you’re probably using some feature of the .NET framework to support your presentation layer; either WPF or ASP.NET. And when you created your WPF or ASP.NET application, Visual Studio helped you out by creating a lot of… stuff. Mostly boilerplate code to handle “frameworkey” things that developers don’t want to deal with. No question; WPF and ASP.NET are HUGE timesavers for software developers.

And they are also the cause of why most software development projects will never reach the “100% code coverage” panacea that many managers crave.

And this is OK. But we need to understand how use of these libraries skews code coverage percentage.

When a developer writes a unit test they are expecting to exercise the code in the method they are testing as well as the code in any private methods on the same class that the public method we are testing uses. And external resources, and ideally any third party frameworks, should be mocked out and not covered by the unit test.

This is logical and what most developers expect. And if we’re writing code that’s not in the presentation project, our code coverage makes sense; the only code in the class or library (generally) is the code we create. And, or course, we would never DREAM of writing code without having a test for it first, right? RIGHT?!

It’s when we get into the presentation project that things get a little complicated. Remember all that code that Visual Studio crated for your to take care of the stuff you didn’t want to do? Well, just because you didn’t write it doesn’t mean it’s not there.

If you’re Test-fu is strong, you are no doubt creating tests for your Controllers/Model/ViewModels/etc. That’s good. But, since you’re generally not running in the same application context during testing that you would be running in during execution, all that boilerplate helper code that was created is never going to be tested. Which means while that code counts toward your “total codebase” (the number of lines of code in your application) they can’t be covered by a unit test.

Even if you could reach it with a test your test context is not going to have the services and facilities the WPF/ASP.NET runtimes need to execute correctly. And even if you could create those services and facilities, you would be flirting pretty heavily with having an integration test (still important!) but you wouldn’t really have a unit test anymore. In any case, trying to cover this code with a unit test is really just not practical.

We Should Probably Just Give Up Now Then, Right?

Nope.

The problem isn’t the boiler plate code, it’s the way we are measuring the code coverage percentage. Ideally we don’t even want the code coverage tool looking at this code for purposes of determine our “full code base.”

When determining what get’s measured for code coverage metrics we want to exclude the boilerplate code and only check the code that we (as the development team) actually write. We also want to make sure that we that we exclude any source code that ships as part of a framework or library we are using. Most .NET libraries ship as pre-compiled assemblies, but there are some that still ship with a source component, those need to be excluded. Does your application have integration tests? Guess what, those are probably being analyzed by your code coverage tool as well.

The good news that most code coverage tools enable you to exclude code on a project or class level. Some even let you exclude on the method level. As your project continues to grow I recommend that you update your “exclude list” to accommodate new boiler plate code, libraries and tests that will be added to your solution.

By excluding the code you don’t write, your code coverage number should be more inline with the impact of your unit tests on your code. When you are only testing your code, 100% code coverage is very achievable. But what does a number that is less than 100% mean? In my next post on this topic I’ll discuss situations where your code coverage dips, what to do about it, and why it’s not always a bad thing.