Is TDD old news? Why or why not?

When we shared this on Twitter, we had lots of discussions. Clearly a hot topic. What do you think?

Here are some of the discussions

It’s been around a long time. Depressingly, at #DeliveryConf last week, some leading practitioners said they see less and less of it, even though it is shown to reduce bugs by 70% (more, in my experience). It’s hard to learn, ppl won’t make the big investment, despite ROI.

Devil’s advocate
TDD is not agile.
It delays the, inspect and adapt, feedback loop we strive for. Also our code visible, transparent, to all so there is already enough possibility to check the code.

well, I’m not qualified to defend TDD, though having worked on teams who practiced it well, I can attest to how it helped build a quality software product. There are studies that people like @jezhumble &@davefarley77 pointed to at #DeliveryConf, but those don’t sway people!!

IMO it is a matter of helping highlight another perspective. Is time for a story to be off your plate important? Or time until value is seen? If we track cycle time as idea->prod (rather than just “dev-ing”) & we track rework it changes whether you think TDD even slows you down

TDD is not BDD. Especially for API development, TDD is a really good approach. It is very old news but still very useful.

BDD has been described by Dan North innorder to remain the benefits about having conversion between dev, test, and product owner. The goal is to define nominal use cases and unthinking use cases. BDD is human. TDD is design

Most certainly not old news. I did TDD today. Also, people are still struggle in adopting it so TDD consulting services are still hot like it was discovered yesterday.

Absolutely relevant. Can tests be written after? Yes. In my experience this leads to missing test coverage while your test coverage is near or at 100%. TDD is good practice because it changes how you implement. It gets you thinking about correct behavior not current. Unit testing is not intuitive. Most devs kind of suck at it. That’s fine because it takes practice.

1 Like

My take is relatively short.

Is TDD useful for /some/ people in /some/ context?
Since the answer is “yes”, then TDD is still relevant.

For me, personally, unlike some of the other comments, TDD actually decreases the time I spend designing and implementing solutions. When I focus first on the “test”, then my thoughts are more structured, I’m less likely to take tangents, and I come up with a working solution to a problem more quickly than if I just started coding. And since the tests are very limited in scope, there are fewer issues after I’m done coding as well.


This has been a little of a favorite topic of mine as of late. I have for a long time, as a tester, argued that TDD is not a test tool but a design tool. Now, I’m no longer sure why I have made that distinction but it goes somewhere on the lines of it is a proactive tool that helps you avoid making errors instead of a reactive tool which helps you find the errors you have made. Some great minds in the industry consider TDD not to be optional but rather a fundamental approach to professional software development. To which I fully agree.

One of them also made an interesting comment which captures my thinking of it. The comment was on the line of I do TDD, but I do not write tests. Since he was solving problems for which he already knew the correct design, hence he did not need to use that tool to help drive his design. He still specifically though about the design of his software before implementation.

As for the wide spread usage of it I have not seen a shift in either direction. The illusion that you lose time by writing tests first is as common as ever. The unit test / test automation / code coverage conversation is still around and is hurting TDD still. As stated above, testing and TDD are as unrelated as testing and coding. And my final though is that if it is diminishing we need to stop that and make TDD a fundamental coding skill.


I’ve tried and failed to do TDD, it’s mostly incompatible with how I think. I think it could work if you had a clearly defined problem, but when you don’t it’s nearly impossible. Advocates will (and do) tell me that TDD is actually best in that kind of situation, but I’m at a loss to see how. How do you write a test when you don’t know what it is that you’re doing? I don’t know.

For me, I prefer a slightly modified approach: prototype, write tests, refactor. Which isn’t what the TDD tutorials I’ve read in years gone by have advocated, but actually lets me know what the problem I’m actually trying to solve is.

This is a good opportunity to ask a problem I’ve been fighting for a while now. Inheriting production support and maintenance for a number of projects that were delivered through Agile without any clear requirements management means I struggle to put any change control around releases and am constantly hit with regression issues.

I’ve been pushing to implement TDD to act as the requirements management layer.

Without TDD I don’t see another systematic way of managing regressions without the customer claiming ‘it was always meant to do <thing that it’s now not doing>’.

I think this came from a recent cucumber blog that I read, but I prefer the all encompassing umbrella of EGD - Example Guided Development.

It promotes the idea that TDD, BDD, Specification By Example and ATDD are all really part of the same overall whole, which is Developing based on working examples, or Example Guided Development.

BDD offers up the overall collaboration approach where we can run sessions (example mapping, three amigos etc.) to drive out feature files (or if you prefer, specifications by example, provided you write them like that) either at a low level which can be used to inform Unit testing (supporting the use of TDD at that level of development) or at a higher overall feature/functionality level (supporting the use of ATDD in the wider development of a feature).

Whether you then choose to automate those feature files is another decision, but one that you can decide to take without the need for any additional work to turn test scripts/feature requirements into a feature file to run cucumber, as you’ve already got it in that format.

If your agile team adopted a BDD approach then your three amigos session would deliver an agreed Feature File that is not only used as the specification for the development but it also acts as an agreement on how that feature should operate.

Agile isn’t about having no documentation (that’s a minefield of issues, which you are now experiencing), it’s about having the right documentation.

The beauty of a feature file borne out of good BDD practices is that it provides a single document that:

  1. Acts as a contract from the business on what is being requested
  2. Acts as a specification for the developer on what should be built
  3. Acts as a high level script of the tester on how it should be tested

If any party at the end wants to dispute what has been delivered then the three amigos session should be revisited and the missed requirements should be highlighted for further development, but there is no room for people to claim “it was always meant to work like X”.

1 Like

I think the issue you are having is highlighted in this line:

“How do you write a test when you don’t know what it is that you’re doing?”

TDD/ATDD relies on you knowing what you are ultimately aiming at, which requires good planning and requirements gathering upfront. If you’re just being sent of to code a feature without this work having been done then I’d agree that TDD is going to be pretty useless.

But that raises a bigger question around the practices being utilised before you even get to coding a feature being requested.

I’d say if you don’t know what it is you’re doing, then you shouldn’t go ahead with writing either tests or code - that would be the point I’d be digging my heels in as part of a development team and saying the story is not well enough understood to be brought into play by the team.
Chris makes a lot of good points above about the value of BDD to bring clarity at the outset about what you’re trying to achieve in a manner that both the stakeholders and the implementers have in common. Speaking as someone currently building automated API tests in Cucumber, if you’ve written the feature file well then creating the automated tests should then just involve wiring things up within your test framework with a minimum of effort.

1 Like

And on the subject of writing good feature files I’d strongly recommend having a read of this blog from Andy Knight:

Clicking a link and pressing a button etc. are not behaviours. Writing feature files as prescriptive test scripts just leads to unneeded complexity in the feature file which makes it difficult to get the benefits out of the feature file that it is intended to deliver. Not to mention making them difficult to read and making them more inaccessible to newcomers.

High level behaviours in the feature file, linking to lower level actions/method calls in the step definitions.

Something I’ve found useful as well is review the coding as each Step is delivered. This avoids building the later steps on sand.

If the developer thinks they’ve completed the “Given”, then organise a short 15-30 minute review with the three amigos and ensure that the Given being delivered meets the expectations of all parties. If it doesn’t then your requirements are incomplete and you go back to the example mapping/three amigos session to drive out the other things that may be missed.

These short reviews will maybe take anything from a couple of hours up to a days worth of effort (depending on how many times you are forced to go back to the requirements gathering sessions) when all added together, but I guarantee that will be a shorter spend than waiting until the feature is fully delivered and handed over for testing (without the tester having the in depth knowledge of the business user who is assuming that something will be built in such a way to take account of their manual workarounds that they told nobody about) only for it to make it into production and have users complaining that it doesn’t work as expected (or worse).

It’ll feel alien at first and you’ll have to fight the inevitable cries of “BUT THIS IS HOW WE’VE ALWAYS DONE IT!” but once the approach is understood, adopted by all and embedded in your process it will pay for itself again and again.

The Test Manager at a previous employer had a sign on her desk “Tradition - just because you’ve always done it that way, doesn’t mean it isn’t incredibly stupid!”

1 Like

I need that sign, I would direct so many people towards it and save myself no end of time to handle other things.

And probably aid my performance reviews by not having to explain why I thought that directing Karen, from the business, to leap off the top of Mayan pyramid in a gesture of self human sacrifice to appease the old gods was an appropriate answer for explaining why change was good.

It came from the Demotivators site, I pinched one of the images some years ago which was of a Mayan pyramid and had the legend “Sacrifice - all we ask here is that you give us your heart” :smiling_imp: No longer have the printout of it unfortunately, I gave it to a colleague on leaving along with most of my other deeply cynical desk ornaments…

Now looking for a way round the Group Policy Set Background for the PC so I can swap the company logo and colour scheme with the Tradition.jpg.

1 Like

I’m a bit flabbergasted at the person who responded TDD delays the feedback loop. I don’t see how you can get a faster feedback loop than running your test suite in a few seconds, depending on how it’s set up and what sorts of tests you’re running. I’d have loved to have heard more about that person’s thinking.

TDD (and I’ll use a broad umbrella that encompasses BDD, ATDD, etc.) is as much about design and steering lean thinking around building out your system–as others here have noted. It’s also about helping communication across the entire team, and it’s also an incredible morale and productivity booster.

TDD is hard to get good at , and often teams need outside help to guide them along the way. As Dominic1 and others have pointed out, trying to master TDD alone is daunting and loaded with failure.

As a tester I LOVE being in environments that practice TDD–I’m able to focus my energies and skills in the more complex, high risk/value areas versus having to do validations of the entire codebase.

I wouldn’t call TDD “old news” because far too high a percentage of our industry still doesn’t put in the effort to do it–and an embarrassing percentage doesn’t do any form of automated testing, regardless of when they’re written.

I’ve worked in environments that don’t do TDD. I now work in an environment that mandates it and is enthusiastic about its benefits and value. As a consultant I now spend a fair amount of time going back into non-TDD environments and helping them clean up codebases.

I know what environments I prefer to work in…


Like Agile, like DevOps, TDD/BDD are as much about mindset as they are about tools and practices. If the organisational culture of a business isn’t conducive to them then the tools and practices can easily become dead weight on the development process, but if the shared mindset is there, then the good stuff starts to happen…