Thinking and TDD

The cycle of TDD, once again in brief, is to write a small test, ensure it fails, get it to pass, review and clean up the design (including that of the tests), and ensure the tests all still pass. You repeat the cycle throughout the day, keeping it short to maximize the feedback it gives you. Though repetitive, it’s not mindless—at each point you have many things to think about. ​Thinking and TDD​, contains a list of questions to answer at each small step.

To keep things moving, I’ll assume you’re following the steps of the cycle and remind you of them only occasionally. You may want to tack to your monitor a handy reminder card of the cycle.

For our next test, we tackle rule #2 (“replace consonants with digits after the first letter”). A look at the replacement table reveals that the letter b corresponds to the digit 1.

The test fails as expected.

As with most tests we will write, there might be infinite ways to code a solution, out of which maybe a handful are reasonable. Technically, our only job is to make the test pass, after which our job is to clean up the solution.

However, the implementation that we seek is one that generalizes our solution—but does not over-generalize it to support additional concerns—and doesn’t introduce code that duplicates concepts already coded.

You could provide the following solution, which would pass all tests:

That code, though, does not move toward a more generalized solution for the concern of replacing consonants with appropriate digits. It also introduces a duplicate construct: the special case for "Ab" resolves to zero-padding the text "A1", yet we already have generalized code that handles zero-padding any word.

You might view this argument as weak, and it probably is. You could easily argue any of the infinite alternate approaches for an equally infinite amount of time. But TDD is not a hard science; instead, think of it as a craftperson’s tool for incrementally growing a codebase. It’s a tool that accommodates continual experimentation, discovery, and refinement.

We’d rather move forward at a regular pace than argue. Here’s our solution that sets the stage for a generalized approach:

We run the tests, but our new test does not pass.

The padding logic is insufficient. We must change it to account for the length of the encoded string.

Our tests pass. That’s great, but our code is starting to look tedious. Sure, we know how encode works, because we built it. But someone else will have to spend just a little more time to carefully read the code in order to understand its intent. We can do better than that. We refactor to a more declarative solution.

We’re fleshing out the algorithm for Soundex encoding, bit by bit. At the same time, our refactoring helps ensure that the core of the algorithm remains crystal clear, uncluttered by implementation details.

Structuring code in this declarative manner makes code considerably easier to understand. Separating interface (what) from implementation (how) is an important aspect of design and provides a springboard for larger design choices. You want to consider similar restructurings every time you hit the refactoring step in TDD.

Some of you may be concerned about a few things in our implementation details. First, shouldn’t we use a stringstream instead of concatenating strings? Second, why not use an individual char where possible? For example, why not replace return word.substr(0, 1); with return word.front();? Third, wouldn’t it perform better to use return std::string(); instead of return "";?

These code alternatives might all perform better. But they all represent premature optimization. More important now is a good design, with consistent interfaces and expressive code. Once we finish implementing correct behavior with a solid design, we might or might not consider optimizing performance (but not without first measuring; see ​TDD and Performance​ for a discussion about handling performance concerns).

Premature performance optimizations aside, the code does need a bit of work. We eliminate the code smell of using a magic literal to represent the maximum length of a Soundex code by replacing it with an appropriately named constant.

What about the hard-coded string "1" in encodedDigits? Our code needs to translate the letter b to the digit 1, so we can’t eliminate it using a variable. We could introduce another constant, or we could return the literal from a function whose name explains its meaning.

We could even leave the hardcoded string "1" in place to be driven out by the next test. But can we guarantee we’ll write that test before integrating code? What if we’re distracted? Coming back to the code, we’ll waste a bit more time deciphering what we wrote. Keeping with an incremental delivery mentality, we choose to fix the problem now.