Write a better story, with tests


Thanks Dion, I really enjoyed reading your analogy between storytelling and programming. When we struggle with some code, it usually reads like a sequence of sloppily written computer instructions.

I’ve been thinking about what I like about writing tests and why it’s important, as opposed to something you don’t really enjoy and only do because it’s ‘good for you’. I guess just like flossing or jogging, the trick is to actually learn to enjoy it.

I’de like to contribute to the flow of your story and write about why I think tests help you tell better stories with your code.

Taste your food while you prepare it

I really love writing tests. I don’t do TDD, I just write tests when I want to. I usually start when I have written quite a bit of functionality down and the overall ‘structure’ of the code is clear.

When that point is reached, I basically develop tests at the same times as I write the main code and run the tests every 3–5 minutes(those I am working on only, not the whole suite).

To me writing tests while developing some feature is something necessary in order to stay productive and enjoyable to boot.

Like a chef who tastes his food while it’s cooking, it’s a way to continuously make sure you’re working in the right direction and make small adjustments when issues do come up.

Writing tests as part of the story

Writing code is very much about communication, not with the machine but with humans.

for("boolean"==typeof g&&(j=g,g=arguments[h]||{},h++),"object"==typeof g||n.isFunction(g)||(g={}),h===i&&(g=this,h--);i>h;h++)if(null!=(a=arguments[h]))for(b in a)c=g[b],d=a[b],g!==d&&(j&&d&&(n.isPlainObject(d)||(e=n.isArray(d)))?(e?(e=!1,f=c&&n.isArray(c)?c:[]):f=c&&n.isPlainObject(c)?c:{},g[b]=n.extend(j,f,d)):void 0!==d&&(g[b]=d));return g}

Machines love to execute minified code like the above, they love it so much that it will run faster than code written with proper formatting.

Humans in general agree that such code is hard to read. Instead we try to write code that is ‘a good read’.

Basically writing code is not unlike writing a novel or article. If you want people to enjoy what you write, you need to keep your audience in mind and write for them.

Code is not just meant to be read, but also to be executed and have some effect on the world around it. Writing clear code will help your audience reason about it. Writing tests will give people a clearer idea of what effect your code is supposed to have on the world.

Writing tests is communicating across time.

If someone in the future were to change the effect of your code, he or she will automatically be warned by a test failure on the next test run. That person will then have an easier time to reason about the effect of their work.

If the change was unintended, it will be relatively easy to take a step back and fix it. If the change was intended, this new author will have a proof that the intended change really was brought about. Updating the tests to reflect the new effect of the code will keep the legacy running.

When you write tests for your code, it’s almost like sticking around for the next person to ask you: “how is this actually supposed to work?” or “what happens if I make this change?”.