How to Use This Book

I designed the chapters in the book to function as stand-alone as possible. You should be able to pick up a random chapter and work through it without having to fully read any other chapters. I provide ample cross-references throughout to allow you to jump around easily if you’re using an ereader.

Each chapter begins with a quick overview and ends with a chapter summary plus a preview of the next chapter. I chose the names of these brief sections to correspond cutely to the initialization and cleanup sections used by many unit test frameworks—“Setup” and “Teardown.”

The Source

The book contains numerous code examples. Most of the code presented will reference a specific filename. You can find the complete set of example code for this book at http://pragprog.com/book/lotdd/modern-c-programming-with-test-driven-development and also at my GitHub page, http://github.com/jlangr.

Within the code distribution, examples are grouped by chapter. Within the directory for each chapter, you will find numbered directories, each number effectively referring to a version number (which allows the book to use and show examples of code changing as you progress through each chapter). As an example, the code with caption c2/7/SoundexTest.cpp refers to the file SoundexTest.cpp located in the seventh revision of the Chapter 2 (c2) code directory.

Book Discussion

Please join the discussion forum at https://groups.google.com/forum/?fromgroups#!forum/modern-cpp-with-tdd. The intent for the forum is to discuss the book as well as doing TDD in C++ in general. I will also post useful information regarding the book.

If You Are New to TDD: What’s in the Book

While this book is geared to all, its primary focus is on programmers new to TDD, so its chapters are in a correspondingly sequential order. I highly recommend you work through the exercise in Chapter 2, ​Test-Driven Development: A First Example​. It will give you a strong feel for many of the ideas behind TDD as you work through a meaty example. Don’t just read—type along and make sure your tests pass when they should!

The next two chapters, Chapter 3, ​Test-Driven Development Foundations​ and Chapter 4, ​Test Construction​, are also essential reading. They cover core ideas about what TDD is (and is not) and how to construct your tests. Make sure you’re comfortable with the material in these chapters before learning about mocks (see the Chapter 5, ​Test Doubles​ chapter), a technique essential to building most production systems.

Don’t skip the chapter on design and refactoring (Chapter 6, ​Incremental Design​) just because you think you know what that means. An essential reason to practice TDD is to enable you to evolve your design and keep your code clean continually through refactoring. Most systems exhibit poor design and difficult code, partly because developers aren’t willing to refactor enough or don’t know how. You’ll learn what’s far enough and how to start reaping the potential benefits of a smaller, simpler system.

To wrap up core TDD techniques, Chapter 7, ​Quality Tests​ takes a look at a number of ways to improve your return on investment in TDD. Learning some of these techniques can make the difference between surviving and thriving in TDD.

You’ll of course be saddled with the struggles of an existing system that wasn’t test-driven. You can get a jump start on some simple techniques to tackle your legacy code by reading Chapter 8, ​Legacy Challenges​.

Just past the legacy code material, you’ll find a chapter dedicated to test-driving multithreaded code. The test-driven approach to TDD may surprise you.

The next chapter, Chapter 10, ​Additional TDD Concepts and Discussions​, dives deeper into fairly specific areas and concerns. You’ll discover some up-to-date ideas around TDD, including some alternate approaches that differ from what you’ll find elsewhere in this book.

Finally, you’ll want to know what it takes to get TDD going in your team, and you’ll of course want to make sure you’re able to sustain your investment in TDD. The last chapter, Chapter 11, ​Growing and Sustaining TDD​, provides some ideas that you will want to incorporate into your shop.

If You Have Some Experience with TDD

You can probably get away with picking up chapters at random, but you’ll find a lot of nuggets of hard-earned wisdom strewn throughout the book.

Conventions Used in This Book

Any sizeable code segment will appear separately from the text. When the text refers to code elements, the following conventions are used:

• A ClassName will appear in the same font as normal text (“text font”) and will be UpperCamelCase.

• A TestName will also appear in the text font and be UpperCamelCase.

• All other code elements will appear in a code (nonproportional) font. Examples of these include the following:

  • functionName (which will show an empty argument list, even if it refers to a function declaring one or more parameters). I will sometimes refer to member functions as methods.

  • variableName

  • keyword

  • All other code snippets

To keep things simple and waste fewer pages, code listings will often omit code irrelevant to the current discussion. A comment followed by ellipses represents obscured code. For example, the body of the for loop is replaced in this code snippet: