In programming, we use a methodology called test-driven development. For every piece of a program we write (often called a module), we also write an accompanying suite of test cases. Ideally, you won’t find a single piece of source code that goes untested. It sounds slower, but it actually improves quality so much that it has become (mostly) uncontroversially accepted as a best practice.
Testing a piece (a unit) of code is pretty simple. Each little test asserts an assumed behavior by following a similar pattern. It sets up the environment in which that behavior should happen, runs the relevant unit of the program, and asserts the expected result. You’ll find dozens, hundreds, or thousands of these little tests for a given project, and importantly, no one may change how the project works without making a test case for their change and proving it works, independent of the other parts.
Better yet, to an extent, tests can replace explanatory comments. By encapsulating the expectations for your program, I can better describe a program’s design by illustration. Unit tests therefore serve as documentation, sometimes even the only way to understand a program.
I’m beginning to see how it might be useful to apply the test-driven model to writing. I want my writing to make a strong, believable case, against which readers can make unquestionable assertions. I’ve heard the advice to “show, don’t tell,” and I always thought it meant something like including supporting detail. Maybe that’s not quite right. The advice is not to tell at all, instead of simply backing it up. It tells me both what to write and what not to write. Just like with a unit test, I don’t need to stop and explain.
For example, suppose I want to describe a character who loves another. I might say, “Alice loves Beth.” But that’s clumsy. It sticks out of the story, rather than reading as part of it; I’ve stopped telling the story to impart this premise. Worse yet, “love” is a slippery word—it means something different for each of us. What kind of love is this? Family love? Romantic love?
What if my idea of love falls outside the reader’s experience? That is to say, what do I have to say about love itself? “Alice loves Beth” squanders the opportunity and remains silent on the subject.
In fact, let’s not say “love” in the first place. That word carries a lot of baggage. Maybe I’m not even describing something the reader would ever qualify as love. I might find I’m just bluffing, and the reader only has to call my bluff for the assertion of love to fail.
Suppose instead I write a passage like this.
Taking it down from its hanger at the back of the closet, Alice held Beth’s shirt close and inhaled slowly, afraid that she’d exhaust the source of Beth’s lingering scent. Like a flashbulb, it revealed fleeting memories, which rushed into Alice’s mind’s eye barely long enough to register before slipping away again.
I didn’t say, “Alice loved Beth,” nor did I say, “Alice missed Beth,” but who could question that those statements are true? And there’s more. We know Beth is gone, in some form that allowed her to leave behind a shirt but not much else. A faded scent demarcates a rough idea of the time passed. Something irrevocable happened. A bad breakup? A death? Possibly Alice is moving, or maybe packing up Beth’s belongings. I didn’t even indicate whose closet Alice was in. We do definitely get a sense of some romantic love that could have involved cohabitation, so that distinction may be immaterial.
My point is, it’s not just about how you feel after you read the passage above. It’s more about stating what’s immediate and undeniable, making a case, while leaving out flimsy or even misleading commentary. Within this context, every action in the story fits and drives the narrative forward. The idea of test-driven writing—even though there are no actual tests involved, beyond the reader—helps me better understand what to write, and what not to write.