Test First vs Last: Introduction

A psychological comparison of writing test first and last.

The two essays I've recently published on Test-Driven Development (TDD) prompt familiar questions:

1. Why should I switch to writing tests first if I’m already writing tests last?

2. Do you always do TDD, even in your startup?

This post introduces my experiment on publishing a series in this newsletter containing smaller, more digestible insights. If you have similar questions to the ones above, follow along. Hopefully, they’ll be answered at some point.

What is being compared?

What’s going to be compared in this series will be the reduced version of Test-Driven Development (TDD) and Test-Last Development (TLD). I’ll be focusing solely on the difference in the sequence of writing tests, despite TDD containing more principles. I’ve hinted previously that the sequence of steps matters more than you might think, as explained in Making a Nice Cup of TDD, and I plan to delve even deeper. Because of this focus, I’ve intentionally chosen not to name the series “TDD vs TLD”. Besides, these two acronyms are hard to distinguish with one letter difference.

Ultimately, we’ll be comparing writing tests first and tests last. We’ll assume that in both methodologies, engineers will have the discipline to refactor after.

What you should expect from this comparison will be less about the code, as that’s been covered very often. Rather, I’ll compare what’s happening in my mind - the psychological experience in practising these two techniques. This follows my previous theme of exploring our cognitive limits and the DevEx framework in my other essay, Why TDD Enhances Developer Productivity.

Having said that, you may wonder if my views are entirely objective or if there’s a preference for one technique over the other.

Will this series contain a bias towards TDD?

Short answer: Possibly.

However, in more depth, I attempt to be as objective as possible. I’m not really interested in siding in a certain technique, I’m more interested in understanding what to practice, when, and why, but inevitably I may conclude that one is better than the other.

I can be objective in this comparison because I have practised both writing test first and test last. Most TDD practitioners I know have practised writing tests last too before they learned about TDD, and that’s how they started. Writing test last was the default for me too.

I also coach teams to practice TDD. Therefore, I can see what engineers are noticing when they write tests last. When the emotion hits them hard, I can see it. They share a similar experience as when I practice writing tests last.

These aspects should hopefully maintain my objectivity throughout the series, so stay tuned!