TDD @ BBC Sport - "TDD is the reason I'm never stressed" (Paul Hammond)

Paul Hammond shares his story - how he started TDD when he joined BBC a decade ago, and how TDD reduced stress and helped him refactor safely.

👋 Hello, this is Valentina with the free edition of the Optivem Journal. I help Engineering Leaders & Senior Software Developers apply TDD in Legacy Code. To get these articles in your inbox every week, subscribe:

---

Paul Hammond, Contract Web Developer from the UK shared his TDD success story on LinkedIn (with 700+ likes and 50+ reposts!). He started TDD over a decade ago, when he joined BBC. It’s a long and very insightful post, hence I’ll be going over it step by step, breaking down lessons learnt from Paul’s success story.

Lesson #1: TDD should be a job requirement

BBC had TDD as a job requirement. That’s why Paul needed to get some practice prior to joining BBC. That’s exactly what successful organizations do - they don’t just require you to be familiar in a certain tech stack, but in TDD as well.

Lesson #2: Test behavior, NOT implementation!

Many developers don’t know that Kent Beck had said:

“Tests should be coupled to the behavior of code and decoupled from the structure of code. Seeing tests that fail on both counts.” - Kent Beck

Fortunately, Paul came across Ian Cooper’s talk, where he learned to write tests that are coupled to behavior, rather than implementation details, to help it easy for us to make changes in source code without breaking tests all the time:

Lesson #3: Tests should enable safe refactoring

Based on learning how to write tests coupled to behavior (and NOT internal implementation details), it meant that Paul and his colleagues were able to refactor internal code with high assurance, without having to change tests:

Lesson #4: Tests should provide fast feedback

Tests run by developers should provide fast, near real time feedback. That way, developers can know if they introduced any regression bugs:

Note: I wrote about developer-facing tests in the Commit Stage. They are fast developer-facing tests. They are fast enough to run on the Pipeline as part of Commit Stage, and running them locally as part of the Pre Commit Stage.

Lesson #5: Showcase TDD to other developers

After seeing the benefits of TDD at BBC, Paul continued to apply TDD at his next jobs, and showed TDD to countless developers who worked in completely different projects.

Lesson #6: TDD should be our industry standard

TDD helps us work in a safe way, it helps eliminate stress. TDD should be the mainstream way to develop software.

I completely agree with Paul’s statement:

TDD… should be a standard by now.

That is exactly why I’m writing about TDD on Substack!

TDD should be the mainstream way to develop software across the world. The problem is, most companies are still stuck at level zero in automated testing, developers never had a chance to learn those skillsets. This motivated me to take what I learnt working as a Technical Coach and make it accessible to you in the TDD in Legacy Code series.

Share your success story

I would like to feature TDD success stories in future editions. To share your story, write a comment below. 💪

---

Want to apply TDD in practice?

You tried TDD, but it didn’t work. That's why I'm going to help you practice TDD step-by-step. Apply TDD on a sandbox project. Access TDD in Legacy Code.

---