Introduction

Despite the current explosion in programming languages, C++ soldiers on. It is the fourth-most popular programming language, per the July 2013 Tiobe index. (You can find the latest index at http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html.) The 2011 ISO standard (ISO/IEC 14822:2011, aka C++11) brings features to C++ that may increase its acceptance...or at least soften objections against its use.

C++ remains one of your best choices for building high-performance solutions. If your company’s products integrate with hardware, chances are you have a sizeable existing system built in C++. If your company has been around since the 1990s or earlier, chances are you have a long-lived C++ system, and chances are also good that it’s not disappearing anytime in the next several years.

Given that you’re now working in C++, you might be thinking one of the following things:

• It’s 2013. Why am I back in this difficult (but entertaining) language that I thought I’d abandoned years ago? How am I going to survive without shooting myself in the foot?

• I’m a seasoned C++ pro, I know this powerful language like the back of my hand, and I’ve been developing successfully for years. Why would I need to change how I work?

• Where’s my paycheck?

My personal sentiment is that I first worked with C++ around the early 1990s, before the rise of things like templates (and template metaprogramming!), RTTI, STL, and Boost. Since then, I’ve had a few occasions where I’ve had to return to the powerful language and have done so with some dismay. Like any language, C++ allows you to shoot yourself in the foot—but with C++, you sometimes don’t realize you shot yourself until it’s too late. And you’re probably missing more toes than folks working with other languages.

If you’ve been working with C++ for years, you likely have adopted many idioms and practices to help ensure your code remains of high quality. Die-hard C++ veterans are some of the more careful programmers across all languages because surviving in C++ for so long requires meticulous care and attention to the code you craft.

With all this care taken, one might think that the code quality on C++ systems should be high. Yet most C++ systems exhibit the same problems we all see time and time again, usually regardless of language.

• Monstrous source files with thousands of lines

• Member functions with hundreds or thousands of lines of inscrutable code

• Volumes of dead code

• Build times extending into several hours

• High numbers of defects

• Logic too convoluted by quick fixes to be safely managed

• Code duplicated across files, classes, and modules

• Code riddled with long-obsolete coding practices

Is this decay inevitable? No! Test-Driven Development is a tool you can master and wield in order to help stave off system entropy. It may even reinvigorate your passion for programming.

If you’re simply seeking a paycheck, there are plenty of C++ jobs out there that will keep you employed. However, C++ is a highly technical and nuanced language. Wielding it carelessly will lead to defects, intermittent failures, and possibly multiday debugging sessions—factors that can put your paycheck at risk. TDD can help.

The effort required to add new functionality on such large, long-lived C++ systems usually disappoints and often is inestimable. Simply understanding a passage of code in order to change a few lines of code can take hours, even days. Productivity is further drained as developers wait hours to determine whether their changes compiled and wait even longer to see whether they integrated well with the remainder of the system.

It doesn’t have to be this way. Test-Driven Development (TDD), a software design technique devised in the late 1990s, can help you wrestle your C++ system to the ground and keep it under control as you continue adding new features. (Notions of writing tests before code have been around for considerably longer. However, the TDD cycle in its formal, disciplined form was devised by Ward Cunningham and Kent Beck [Test Driven Development: By Example [Bec02]].)

The primary intent for this book is to teach you a disciplined approach for the practical application of TDD. You’ll learn the following:

• The fundamental mechanics of TDD

• The potential benefits of TDD

• How TDD helps you address design deficiencies as they arise

• The challenges and costs of doing TDD

• How TDD can reduce or even eliminate debugging sessions

• How to sustain TDD over time