Test every line of your code. No excuses.

by breeve 18. November 2012 04:28

In December 1776 Trenton, New Jersey was in full control of Hessian troops—who were recruited to help fight for the British. Known for their fighting strength, they helped drive the Americans from New York and New Jersey. If there was a way to beat the British, the Americans couldn’t find it.

That all changed during the night of December 25th, 1776. During that night a nor'easter arose. Confident in their ability to route the Americans in any environment, the storm provided welcome relief. The morning predawn patrol was canceled. So confident were the Hessians that Colonel Rall, the commander in charge, calmed his subordinates by stating: “These clodhoppers will not attack us, and should they do so, we will simply fall on them and route them.”

While the Hessians were making plans for a relaxing night, Washington’s troops were crossing the Delaware into the teeth of the storm. By 8:00 a.m. the first shots into Trenton were fired completely surprising the Hessians. The Americans routed them capturing 896 Hessians and killing 22. The once confident Colonel Rall was dead.

Like the Hessian troops in Trenton who were confident in their abilities, developers can also become too confident but instead of abandoning their patrols they abandon testing their code. The thoughts start innocently enough. Just a simple code change. Get in then get out. No need to run it.

For all the code mistakes developers make nothing is more embarrassing than the obvious one. What time developers save by not running the code is lost in respect among their peers. When these developer aren’t testing their code, they are dreaming of how it ought to run.

Whatever the reasons for not testing code, experienced developers are more susceptible to it. Just like the experienced Colonel Rall neglecting the basics, I have seen code checked in that plain doesn’t work and would have been easily caught if run. Things like a mistyped web link or a for loop that doesn’t terminate correctly. Checking in untested code–even if a simple change–is irresponsible.

Running your code is one thing, thoroughly testing it quite another. My first tech lead was shocked when a bug was found in his code. When his reaction wasn’t shock it bordered on denial. At first I was taken aback by this but soon came to appreciate it. No matter how experienced, he not only tested every line he wrote but thoroughly tested the combinations of inputs. So fortified was his code, that bugs reported on it were rare. Colonel Rall could have learned some things from him.

While my first tech lead’s reaction to bugs was shock, most are not. This is concerning. Did they spend the effort testing their code? Shouldn’t they be more confident in it?

There are many signs of a good developer but none are more important than confidence in their code because of proper testing. Like any good general knows, it’s the basics.



Powered by BlogEngine.NET
Theme by Mads Kristensen

About Me

I am a Principal Engineer with 16 years experience developing and releasing software products. I started developing in C/C++ then moved into .NET and C#. Currently working in Python/Flask and Docker. Have tech lead multiple projects. I have developed products in Windows Forms, ASP.NET/MVC, Silverlight, WPF, and Python. I currently reside in Austin, Texas.

Own Projects

Pickaxe - An easy to use web page scraper. If you know a little SQL and how basic CSS selectors work, no web scraping product will be easier to use.


FligthQuery - Query FlightAware FlightXml API with SQL


Created ASP.NET MVC forum originally targeting home owner associations but now in use by an investor group.


Currently Reading