(^50) 97 Things Every Programmer Should Know
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.POGRAMMR iNG 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 unimple-
mented. 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 log-
ging 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 “funny” data entry. Customers spot a $1M “Bill Gates–shaped
personal massager” on sale in your online store.