The TDD Edition
Keeping builds green, the fourth step of TDD and why TDD doesn't need unit tests.
This week we’ll be talking about TDD.
TDD is an important practice in making software easy to change.
More TDD topics to come, but this week we’ll be talking about:
Keeping Builds Green
The Fourth (missing) Step Of TDD
TDD Doesn’t Need Unit Tests
Keep Builds Green
"The tests are failing but I'll fix it later..."
TDD is all about fast feedback cycles.
But it's also about reducing waste. Why? 👇
When a test is failing, you're getting feedback that what you've done was a mistake.
When that mistake persists... for seconds... then for minutes... then maybe for hours...
It means you're getting off track.
The longer the failures last, the more work in progress builds.
The more work in progress builds, the more waste you're accruing.
And as waste builds it becomes exponentially harder to clean.
Finally, you throw your hands up "Let's break out the debugger".
That's an admission of failure!
90% of your time should be in green.
And when you're in red, get back to green as soon as you can - by whatever means necessary.
Keep your build green at all times!
The fourth step of TDD
TDD has three steps:
Red - write a failing test
Green - make the test pass
Refactor - restructure the code
But there's a fourth step that you may not be aware of.
And it's critical to long-term agility.
You write a failing test.
Now it's time to make that test pass. Right?
Well... maybe.
Pay attention to how the test fails.
What's the failure message?
You want that failure message to describe what went wrong clearly.
Why?
If a test suite never fails, then it's not protecting you from any failures.
A useful test suite will fail sometimes.
You'll be blocked until you fix them.
With expressive, helpful, failure messages, you can easily reason about what went wrong.
With weird, obtuse, "expected 4 got 2" failure messages you'll need to break out the debugger.
Breezing past an unhelpful error message right now means shooting someone else in the foot later.
And that someone might be the future you.
Do yourself a favour and work on making that error message useful before you move on.
The fourth step of TDD is part of step 1 - make the failure message useful.
TDD doesn't need unit tests. 😮
Say what now?
It all starts with TDD being misnamed.
The acronym stands for "Test Driven Development"
So how can tests not be an integral part of this practice?
Dan North came up with the term "BDD" or Behaviour Driven Development.
Back at the start, BDD meant something very different:
It suddenly occurred to me that people’s misunderstandings about TDD almost always came back to the word 'test'.
I started using the word “behaviour” in place of “test” in my dealings with TDD and found that not only did it seem to fit but also that a whole category of coaching questions magically dissolved.
I found the shift from thinking in tests to thinking in behaviour so profound that I started to refer to TDD as BDD, or behaviour-driven development.
- Dan North
TDD is first and foremost about behaviour.
Any way you have of verifying that behaviour is enough to practice TDD.
An early mentor showed me how to test drive code by only using a browser and refreshing the page.
So the next time you do TDD, whether or not you're doing it with automated tests, focus on behaviour, not the test.
Need More?
I have two options:
Book a 1 hour coaching session (normally $200, FREE for a limited time)
Have a great week!