There’s been a battle going on in my mind lately, whether to just fully throw my support behind Behavior Driven Development or continue using Test Driven Development terminology as well. On one hand, I prefer the BDD nomenclature and concepts, even though they’re influenced by and in some cases directly compatible (or even the same) as terms and concepts in TDD. At the same time, I often find myself referencing the terms in TDD in order to keep in touch with people who haven’t made the jump yet.
I really think I just want to drop the whole TDD nomenclature altogether… rather than referring to TestCases, I just want to refer to “those examples” or “that spec.” Instead of saying “when TDD’ing this piece of code” I really want to say “when I’m specifying the behavior for this piece of code.”
I think from now on I’m just going to outright drop the whole TDD nomenclature and just use straight BDD nomenclature… if people are left scratching their heads or asking the difference, I’ll explain, but for the most part I just want to move on and promote a lot of good practices I’ve learned over the years of doing TDD, and I feel that BDD really helps me express those practices better.
So from this day forward, I won’t be referring to “tests” anymore when it comes to unit level specifications… even if I’m using non-spec based frameworks. 
I started doing the same thing earlier this year where I work. I think this was the point that I started making some headway in promoting BDD. I picked up a habit from my colleague Szczepan and write given, when, then sections when I start a junit spec. It helped me make the spec better and promote the ideas/concepts/terminology of BDD better as well.