Becoming a craftsman

As a sometimes cross country and track runner, I was taught and quickly learned that the best way to run any longer distance is to do the second half faster than the first half. In distance running, we call this negative splits. Those of you who have run negative splits know how different it feels from “positive splits” where you run the second half slower. When you finish a race in which you run negative splits you generally finish more quickly, feel much better, and are excited about running the next race. When you finish a race with positive splits you feel wiped out, beaten down (by everyone who managed to do negative splits), and uninspired. Although there may be and probably are physical reasons for these results, much of it is definitely psychological. If you spend the first half of the race conserving energy and then the second half passing people, it doesn’t matter that much that you spent the first half further back than many others. As you begin passing people the psychology of lots of small wins kicks in and really makes you feel good.

But negative splits are hard to do. When the gun goes off your adrenaline is already racing and you want to win. You don’t want people to pass you left and right while you run conservatively. Even when you know through experience the benefits of negative splits, it’s easy to get caught up in the moment and start too quickly. Or it may just be that the race leaders seem so far ahead of you that you have to go faster or lose all hope of remaining competitive. Pride may drive you to run faster earlier. Or it might be a justified fear that by trying to run negative splits you actually start off too slowly and never make up the time.

In the past couple months as I’ve started practicing test driven development of a new feature that I own, I’ve felt very much like I’m in the first half of a distance race. I know that I’m progressing slower than I have in the past, if you simply measure my progress in writing code that will ship. I can feel that I’m taking longer to do what I’m doing. However, I also feel like I’ll be able to complete the feature faster, which mostly means that the bug tail will be much shorter. Looking at the code I’ve written vs what I’ve done in the past I know there is an improvement. The daily process of writing tests, and then writing code that makes them succeed is as addictive as passing people in a race and keeps me excited about the end result, even if I’m moving slower by some measures. At the same time, I feel like a better developer, I’m able to make changes more quickly, and I’m more excited about my work.

Because I’m currently learning about unit testing, TDD, and other agile practices, I admit that I recently considered the possibility of doing some greenfield development. While a part of me would love the experience, the challenge of using these techniques in legacy code to improve the product is very motivating to me. Along those lines, I recently followed an interesting debate about the relationship between unit tests and asserts in production code on an internal discussion list. Microsoft is big enough that you hear from people using all types of technologies and at lots of different stages in the transition to unit testing and TDD.

Assertions

Years ago, the state of the art practices for verifying code included a liberal dose of assertions scattered through the code that would run in a debug build. Generally, an assertion would notify the user and abort the program. When an assertion failed, you could debug to find out what was wrong. Generally the assertions are closer to the problem in the code than any other bad behavior you might see if the assertion hadn’t fired. Often assertions were used to verify contracts along an interface. Unfortunately, in some cases assertions were used in place of proper error handling. At other times assertions were used to verify global state assumptions. Assertions generally lead to two sets of binaries for your program – an official set and a “debug” set that developers and testers can use to find bugs.

Good Guy, Bad Guy

Assertions can often be categorized as either error handling or as there-is-no-way-this-could-happen. Assertions that are used for handling errors are bad. Instead errors should be handled either via a proper return value, or via exceptions. I won’t get into the debate here about which should be used. Assertions that fall into the there-is-no-way-this-could-happen category are probably better handled via code correctness tools that analyze code paths to verify certain properties of the code, though there is probably little harm in using these assertions.

Often assertions were used to do in-place unit testing. External unit testing is a natural next step from such assertions. Before discussing unit tests, however, it’s helpful to note that these assertions were a good thing. They tested the code every time it was run (at least in the debug version) and was often easy to understand with the surrounding code as context.

Unit Tests

Unit tests are a different way of validating code correctness from within the code. Instead of creating two sets of binaries, you essentially create two sets of source code: one that is the program, and one that verifies the program (Note: two sets of binaries may still be created). Unit tests, if written well, can verify the code in ways that are not easy to do with asserts alone. Unit tests are run regularly while writing code, while asserts fire only if a given code path is exercised in some way. Unit tests can specifically test code paths that might not be exercised normally. Unit tests can be written with the code to shape the code itself, if you are doing TDD.

Unit tests can do a lot more … Oh wait, like I said, I’m still new to all this agile stuff. So it was interesting to listen to the agile believers argue against any assertions while others made the case that assertions were useful in some situations. I must admit that the idea of having no assertions at all was shocking at first. But it immediately became appealing as an ideal once I understood how clean code without assertions might be. However, in a large legacy code base with lots of asserts you’re not going to escape assertions easily. And honestly, after some thought and experience, I believe that the two methods are complementary.

Asserts in existing legacy code are an excellent starting point when trying to get the code under test. Using the techniques in Working Effectively With Legacy Code, write tests for your code that exercise it well. Initially, if you’ve got a good set of asserts, positive unit tests can be written that don’t even verify much, as long as your framework interprets asserts as unit test failures. Of course you’ll want to write tests that cover more than just that, but it is a start and will provide some level of safety when refactoring. If your unit test does not interpret asserts as unit test failures you can use a seam (link seam, preprocesser seam) to redefine assert in the binary you compile for unit testing.

Do unit tests make assertions redundant?

In writing new code within the legacy code base I definitely find myself using less asserts because I am writing unit tests as I go. However, certain things are much easier to test with a well placed assert in the code, rather than the unit test. In talking with a colleague the other day I was reminded that making code unit-testable can make it more complex than it has to be. Because of this, I believe that assertions in code can have the beneficial effect of simplifying the code you write by making it somewhat easier to write unit tests around it. This can lead to better factored code that doesn’t make it so obvious that it’s been engineered in order to accomodate unit testing.

Resources

_ASSERT macro , assert , Java’s guide to Programming With Assertions

Unit Testing , Unit Testing Legacy Code