Test(ing) Post

Introduction

This is a short test post to start this blog. But let’s just imagine this was a post about software testing instead.

The Story

Imagine a purely fictional story about my colleague Bob who always insisted on TDD and was fired for underperforming and my other colleague John who never wrote tests and was fired for deploying changes that bricked a production system. As always, the solution is to strike a balance between the extremes.

The Gist

Software development is largely creative and explorative. Test-driven development (TDD) can kill this spirit and slow you down unnecessarily. Instead, write some prototypes without tests and throw all of them away as a personal milestone in your journey to understand the problem. Once you come up with software you want to keep, add documentation and tests. The purpose of which is to allow your future self and other to come back to the code base, understand it and make changes without fear. Let’s call this idea Test-driven Refactoring (TDR).