Losing the "T" in TDD - what do you lose vs. what do you gain?

In a recent post from Jason Gorman he discusses how some people drop the word 'Test' from Test-Driven Development.

I feel their pain... I've felt that way in the past but eventually changed my mind...

Jason explains emphasis of 'Test-Driven Development':

The problem with Test-driven Development is that it's got the word "test" in the title. It's actually not as much about tetsing your code as it is about using tests to specify what code you should write in the first place.

Emphasis of TDD

I'm not so sure that I entirely agree with this statement any more. I used to... For some time now, I've believed that it is as much about specifying what the code should do as it is about testing it...

I'd say it's first about specifying what your code should do; then it's about testing your code to confirm that it does, and continues to do, what it should do... furthermore we apply testing techniques (in a somewhat exploratory fashion) as we write each test (or jot down what tests we're going to write).

Just because it's first about something doesn't necessarily mean it's more about that something. Perhaps because the tests are automated, we tend to forget about the tests doing their testing thing (and that testing techniques were used to create them) once we move on from that class or story...

Honestly though - that is neither here nor there - I don't think it matters where the emphasis is... The fact that we even have this debate is (IMHO) a reaction to the negative effects of the word test... but what of the positive effects?

The 'T-Word'

With the word test in "Test-Driven Development" - I admit that there are pointless discussions to explain to the uninitiated that "no, it's not the sole responsibility of the testers and yes it's about behaviour specification".

Without the word test, we have the problem with pointless discussions to explain that "yes, it does benefit from using testing techniques to determine the 'examples of behaviour' and yes - skilled testers make a valuable contribution to the process".

I've sat on both sides of the 'T-word' fence and I think that it requires some judgement to decide which path you go down depending on the circumstances... what are you prepared to lose when you replace the 'T' in TDD?

The greatest thing that is lost, in my opinion, when we lose the word test is the value of developers becoming 'test-infected', and the resulting relationship that this encourages between previously segregated disciplines... 'behaviour-infected' or 'example-infected' just doesn't have the same effect - nor as nice a ring to it.

You might think that I'm biased... you'd be right... because a long time ago I first experienced the effects of truly 'test-infected' developers (on a team with a certain Antony Gorman) who embraced both testing and testers in a way I'd not seen before...

When we drop the word test we do lose more than just the word. We lose an important effect on team dynamics arising from 'test-infection'. When we do this, we are admitting defeat in our attempt to overcome our audience's assimilation bias. Admitting that we can't explain TDD in a way that helps the audience move beyond their own preconceptions arising from the word 'Test'... Failing to help them understand the initial (but not necessarily primary) purpose of TDD - design - whilst helping them to also see the relevance of tests and associated skills and techniques.

To those who advocate the substitution of the word 'test'... I ask, is it really a problem with the 'T-word'? Or, is it actually a problem with how we explain it, such that we haven't found a way to overcome 'assimilation bias' in a way that doesn't cost us more than it saves? It's the latter methinks.