BDD: The campaign against testing
Reading the latest posts on the Yahoo XP group, it seems that good TDDers understand that the word "test" is developer-speak for something a little more complex. "Test", in Test Driven Development, encapsulates the idea of specification, design, verification of implementation and the ability to confidently refactor. Regression testing itself is almost a by-product of these uses of the word "test". "Test" is often the first word we think of when doing TDD - you always start with a test - and yet we use it in defiance of its own definition.

I believe that the word "should", and similar elements of Behaviour Driven Design vocabulary, remove the developer-speak, thus helping to bring the code closer to those people who aren't privy to the secret language of software. This includes the customers, and anyone who isn't familiar with TDD.

I believe that the inclusion of developer-speak such as "test", which no longer means what it says, allows us to easily utilise developer-speak in other ways without noticing. We use other laden terms such as "mock", "stub", "functional test", "...Impl", etc. We find ourselves free to name classes after the patterns they mimic and the classes with which they interact (ScalpelSheepVisitor) instead of capturing their role succinctly (Veterinarian). We refer to documentation blindly (JIRA345Test.testHappyPath()). We don't make readable, legible code.

Sometimes, because we can't read our code properly, we mix up the roles and the responsibilities of our classes (ScalpelSheepVisitor shears the sheep too). We assign responsibilities to classes which don't really have responsibility for them (SheepVisitor.getCostOf(sheep)), and we verify that these new responsibilities work (testCostOfSheepReturnedSuccessfully) instead of considering whether they're appropriate.

For people who are already aware of these pitfalls, and who use TDD with care, mindful of what the word "test" really means - BDD will bring little that's new into your life.

For everyone else - try thinking of these things when you code. Don't test; think "What should this class do? What are its roles and responsibilities? What does it do to the things I'm going to give to it?" Then write a method which will describe the class's behaviour. If you need a prefix on the name of the method to make it run then write it, but don't type those letters until the real name has come to you.

I find that using the word "should" helps me think of the name. I find it helps me consider the roles and responsibilities of the class, and the class's interaction with others. I find it keeps me away from that distracting, misleading, misnomer: "Test".