Unit tests = documentation

TL;DR

If you landed on a project and don't know anything about it, look for the tests. They'll speak volumes about the project's history and how it got to where it is, now.

On the other hand, if you're starting a greenfield project, show some compassion for the people who will work after you, and write decent tests.

The longer story

Look, tests are important, period! But I was not that convinced when I first learned about unit testing and TDD, back in 2013. I always felt like testing was weighing me down. 

I wanted to go fast! Later on, I did learn that to go fast you have to go slow, but it took a while. And I still had this nagging feeling that something was beyond my level of understanding. 

But one day it hit me: every time I'd land on a new project, I'd go straight for the tests, and felt quite sad when there weren't any. I didn't need any Product Owner onboarding, nor did I need a senior member to hold hands with. Just the tests.

The reason I was doing this was to understand how complex the software was. But this wasn't the only reason. If people took their time to write unit tests in proper English, lots of knowledge about functional requirements is there for the taking . Reading tests is how you get up to speed with intricate validation rules. That's how you learn about the boundaries of a feature, or areas that weren't cover. 

If testing got introduced from the very beginning, you can reverse-engineer the requirements all the way back to day 1.

As an example, here's what tests on WeRemote.EU look like:

TDD in action

The tests in blue are only written as requirements. They have no body and they serve as my own way of keeping track of the bigger picture. I write 3-10 such tests to roughly define my feature and what it should do from a high-level perspective. 

Empty specs

This approach works wonders when you don't have anyone to pair with. 

Resources

Only one resource, listed below. I appreciate it because it helped me understand TDD and it offered me a healthy perspective on tradeoffs in software development.

Let's Play: Test-Driven Development

Let's Play: Test-Driven Development is a screencast series featuring Java, test-driven development, and evolutionary design. It chronicles the development of a real software project, warts and all. Each episode is about 15 minutes long.

The series ran from August 2010 to June 2012.