Crash: "What's that sound?"
Buck: "It's the wind, it's speaking to us."
Eddie: "What's it saying?"
Buck: “I don't know…I don't speak wind."
from Ice Age: Dawn of the Dinosaurs
BDD is a pretty well-known and well-understood technique in this day and age, and it’s benefits have been described by many (here, here and here, for example). A number of these benefits hinge on language and communication, and it turns out that these can be quite easily diluted. Take this specification, for example:
Given my account is in credit
And my card is valid
And the dispenser contains cash
When I request cash
Then my account should be debited
And cash should be dispensed
And my card should be returned
This is highly readable, even though it contains domain-specific terms (“account”, “credit”, “valid”, “card”, “dispenser”). Consider now this specification, what I call a technical spec:
Given the CreditValidator returns true for my account
And the CardValidator returns true for my card
And the DispenserStatus service returns CashGreaterThanZero
When the DispenserCashRequested event is raised
Then the RecordDebitTransaction of the AccountService should be invoked
And the EjectCash command should be raised on the command broker
And the EjectCard command should be raised on the command broker
While this may be describing the same thing, the wording is technical and tightly coupled to the actual implementation. Implementation is a technical detail and not a feature of the business process, and in fact it generally changes more frequently than business process. So this “technical spec” is simultaneously harder to read and more brittle than the spec that was expressed in business language. Definitely a BDD anti-pattern.