Test-Driven Development
Define Success Before You Start
Posted by Charlie Recksieck
on 2026-05-07
One principle that never goes out of style is the 5 W's and 1 H. Every lead should quickly get to:
Who, What, When, Where, Why, and How
So, when I sat down to just write a little about Test-Driven Development, it seemed like a good idea to put it through those filters.
Who and What
It's an approach employed by software developers.
Basically, "Test-Driven Development" is an approach where you define how a successful version of a program is supposed to behave before you start writing code.
Before I start making a lasagna, I come up with a desired finish which, for me, is always to have it come out very cheesy. Then as I'm prepping and cooking, I've got an ultimate goal for it.
For a software case, right now I'm working on a project that involves a fantasy-league style draft. One piece is what happens if a user drops out of the draft midway. I need to define it - how long it waits, does it autodraft, does it look at last saved queue for desired players?
Yes, you can think of this as being just requirements. The classic approach of TDD is that you define what should happen and run the existing code WITHOUT the proposed improvement. It should fail. Then you keep writing code until the desired result happens.
When To Write It
In Agile environments, I like to have the desired results explicitly stated before anybody even thinks about design or code. Then things get very simple.
I also lied above about the "Who" always being developers. I think a list of desired results should be composed with non-programmer stakeholders. Those in-plain-English results should be what's being tested for.
Where
Software projects, duh.
Nowadays, it's a doubly-good idea to check AI-generated code.
Why
You obviously want to catch bugs sooner rather than later. But now in Agile environments with sprints - and AI able to write code quickly, TDD is a great procedural spot to slow down and make sure any new code didn't break any old features.
How
It's a pretty neat, iterative process:
- Decide a behavior the software should have
- Write a test that checks for that behavior
- Watch the test fail (it better fail - since the feature doesn't exist yet)
- Write the minimum code needed to make it pass
- Clean up or improve the code while keeping the test passing
- Repeat for the next behavior
- Write a test that checks for that behavior
- Watch the test fail (it better fail - since the feature doesn't exist yet)
- Write the minimum code needed to make it pass
- Clean up or improve the code while keeping the test passing
- Repeat for the next behavior
In the Era of AI As a Development Partner
Small startups and large software shops are two very different environments, but they both can use test-driven development very well.
Startups tend to have a "just build it" ethos, but there's a real cost to that attitude. And they're also a breeding ground for trouble when overly-complex code hangs around and gets built on top of.
Larger software projects have larger components involved that have been around for a long time. Writing something new can have unintended consequences which is a perfect time for TDD.
In general, now that AI can generate code instantly, testing for correctness becomes even more important. And with AI agents replacing the work of most junior level coders, TDD is a great tool for the humans to evaluate how well the AI did its job.
Sometime in 2026, we'll have an article that isn't somehow touched by the onset of AI.
