Check out my MoT article, Lessons learned in test-driven development: Software tester edition. I share my lessons on where TDD was easy to adopt, the challenges in trying to inculcate it, and why there’s no one-size-fits-all approach across different work cultures.
After reading, share your thoughts:
Its a really good article and covers a lot of the points I have run into.
Some of the things for me that have stood out in the past from the way I saw that may or may not differ from others.
The goal was often clean efficient code, its developer and unit level focused.
That’s a bit different from a testing goal and from a testers remit so whilst testers can collaborate and contribute it can be a fools errand for it to be tester driven, a way of work forced onto developers.
It does though have side benefits of development by examples which can be discussed and explored, examples I have found whether it be behaviours in BDD or user flow charts in design to be very useful in helping understanding of what needs to be built and the value of that.
The secondary byproduct is often the automated unit level coverage it can provide.
The challenge was often in others seeing it as something else or overly focusing on the byproduct values over the specific clean code value.
Developers unit testing has never been a substitute for a pro-testers risk investigations, it creates a challenge when someone believes it does. Yes it can reduce risk and allow testers to focus more on deeper because they have awareness of some developer coverage of the basics so they do not need to repeat that.
I remain in two minds though as to whether it is training wheels for developers, use TDD to get them to appreciate and write clean efficient code, once that is the natural level is the stricter workflow still of value?
On the other hand if TDD itself does become natural to developers you can get those secondary values on every project without much extra effort.
Measurable success is tough unless your starting point is dysfunction, this applies to a lot of development processes though, even things like someone pushing shift left, its measurable value would also only be relevant if there was a dysfunction in the first place though its often through ignorance of just good practice to consider all testing both tester and developer testing as early as possible.
Still having people treating it as a testing activity is likely the main challenge due to the knock on downsides of this.
A great topic to discuss, thanks for sharing your experiences in an article.
I’ve been working with TDD for some time and there’s been a couple of things that we’ve had to overcome as a team.
Can we even add unit tests to our codebase?
For some legacy code bases, you just cant add or retrofit unit tests. In these situations it’s very difficult to introduce TDD other than at an E2E or acceptance test level.
Education: What are the levels of testing?
From acceptance to unit… what tests are needed where and where do we add them? Which tests get mocked where and what do they cover? Also do we add acceptance tests at the gateway… controller… or where?
Scope: What would we test?
We’ve tried for outside-in TDD but that can be tricky if you don’t have good requirements / Acceptance Criteria. That lends itself to what should be tested / what tests should we be writing to support our red-green-deploy.
Making tests smaller
We’ve needed a lot of team education about how to push tests down into running smaller ones. Any variations of data for edge cases should be run as unit tests that support the existing acceptance tests.
Thank you so much for the thoughtful feedback!
I completely agree that TDD’s true strength lies in encouraging clean, efficient code. When it is mistaken as just a testing activity, it can create confusion and even resentment, especially if testers are seen as imposing it. The idea of “development by example,” as you put it, through BDD or flowcharts, resonates deeply. It supports the notion that TDD isn’t about test artifacts, but about better design conversations. And yes, once clean code practices are second nature, the strictness of TDD might be seen more as a habit than a necessity, but that habit still provides ongoing side benefits, almost “for free.”
Thanks cakehurstyan! These are some very real issues. Retrofitting TDD into legacy systems is almost always impractical, and shifting the team’s understanding of where and how to test is a significant educational challenge. I appreciate the insight about pushing edge cases into lower-level unit tests, it is a great example of how teams can evolve their test strategies over time. It also emphasizes that TDD, when adopted, requires more than just following red-green-refactor, it requires aligning it with architecture, team learning, and delivery goals.
It helps reinforce the hybrid perspective I was trying to highlight a bit too; that unit/integration tests alone do not meet all testing goals, but when applied collaboratively and with clarity of purpose, they can support both development and testing in powerful ways.
The biggest huddle is actually writing unit tests 
TDD is just a step above, I’m happy if they write unit tests and all mutation coverage is covered.
Letting them do TDD just requires that extra level of experience and maturity.
Unit testing & mutation testing, YES
TDD, No.