97 Things Every Programmer Should Know

Chapter 25. Don’t Be Cute with Your Test Data

Rod Begbie

It was getting late. I was throwing in some placeholder data to test the page layout I’d been working on.

I appropriated the members of The Clash for the names of users. Company names? Song titles by the Sex Pistols would do. Now I needed some stock ticker symbols—just some four-letter words in capital letters.

I used those four-letter words.

It seemed harmless. Just something to amuse myself, and maybe the other developers the next day before I wired up the real data source.

The following morning, a project manager took some screenshots for a presentation.

PROGRAMMING HISTORY is littered with these kinds of war stories. Things that developers and designers did “that no one else would see,” which unexpectedly became visible.

The leak type can vary but, when it happens, it can be deadly to the person, team, or company responsible. Examples include:

• During a status meeting, a client clicks on a button that is as yet unimplemented. He is told, "Don’t click that again, you moron.”

• A programmer maintaining a legacy system has been told to add an error dialog, and decides to use the output of existing behind-the-scenes logging to power it. Users are suddenly faced with messages such as “Holy database commit failure, Batman!” when something breaks.

• Someone mixes up the test and live administration interfaces, and does some ...