What Tests Are We Missing?

We’re rarely handed all the specs on a silver platter. Few are so lucky. Even our Soundex rules, seemingly complete, don’t cover everything. While we were coding, some of the tests and some of our implementation triggered other thoughts. We’ll either make mental notes or sometimes write down our thoughts on an index card or notepad. Here’s a list for the Soundex exercise:

• What if we’re passed a word with characters normally considered as word separators, such as periods (for example, “Mr.Smith”)? Should we ignore the characters (like we currently do), throw an exception because the client should have split the word properly, or do something else?

  Speaking of exceptions, how do we test-drive exception handling into our code? In ​Exception-Based Tests​, you’ll learn how to design tests that expect exceptions to be thrown.

• What encoding should an empty string return? (Or can we assume we’ll not be passed an empty string?)

• What should we do with non-English alphabet consonants (such as ñ)? Does the Soundex algorithm even apply? Our isVowel function needs to support vowels with diacritical marks.

Many of these concerns are critical to designing a robust, fail-safe Soundex class. Without addressing them, our application may fail in production.

We don’t have definitive answers for all of these “what ifs.” As programmers, we’ve learned to make decisions at times on our own. But an oft-better route is to ask the customer or even collaborate with them to define acceptance tests (see ​Unit Tests, Integration Tests, and Acceptance Tests​).

“Should the system do A, or should it do B?” In the old days, we would have simply coded our choice and moved on. What we lost in doing so was immediate documentation on which choice we made. Somewhere, the solution for B was encoded in the midst of a lot of other code. Sure, we could analyze the codebase to determine what decisions were made, but often at excessive cost. We’ve all spent too many hours trying to determine how code behaves.

In contrast, test-driving leaves behind a clear document. We waste no analysis time uncovering a choice made moons ago.

Test-driving solutions to any of our earlier “what if” questions is no different from what we’ve done so far. I’ll leave coding the missing tests as an exercise for you.