Skip to main content

Command Palette

Search for a command to run...

The hardest test to write

Published
2 min read
The hardest test to write
P

I build meaningful software by empathising with design, development and business needs. My interests are test automation, functional programming and full-stack web development using NodeJS and other tools.

I like writing tests, because they prove the code will run like I expect. I like it even more when I can write tests before I write code. But often I can’t do that, because I'm still figuring out how the code will work. To put it another way, I'm not sure where I'm going, so how can I ask for directions?

Another challenge is when there is already some code in place that was not written with tests in mind. The code is written like a black box, giving out no secrets, taking no prisoners or arguments. That's why tests should be written first.

Sometimes, I convince myself that it's quicker to do manual tests by refreshing the browser or repeating the commands in the terminal. Then I realise that I'm making slower progress, because automated tests are much faster and less error prone than manual tests.

Do I want to spend my time writing log statements and stepping through breakpoints? No, this sucks, but the alternative is that I'll have to set up Jest, Mocha or Cypress.

Setting up tests is a one-off toll to get on the highway.

Eventually, I find my way. Either the path becomes clear and I know what I'm aiming for, or I'm tired of repeating the same actions over and over - code, run, check, code, run, check. And I commit to writing the first test.

Code, check, repeat.

More from this blog

S

Soliloquy

26 posts

Father, husband, cosmopolitan geek and music lover. Learning how to build beautiful things.