Writing the BDDs... Good Lord, NO!

Listen, you know how it is if you go out to eat and your friend has a big ole chive stuck to a front tooth and you are thinking that you don't want to embarrass your friend by pointing it out, but you also don't want him to walk around looking goofy and let people poke fun at him behind his back? You have a decision to make.

Because I love you and I care about your reputation and your perception in the world I have to tell you something. You sound like a hick. Not a southerner or a mountain person, a hick from some software jerkwater. It's when you say you are "writing the BDDs."

You are not writing the BDDs. BDD is a process. It's not the kind of noun that takes a plural... well, here let me illustrate:

Imagine I told you I was going to "code my programmings?"

How about "I locked my keys in my driving?"

Or possibly "I got a stain on my wearings!"

How bout this one, "Waiter, will my cooking be ready soon?"

Seem odd?

BDD is Behavior-Driven Development. It's a process, not a physical thing.

There is only one of them, that I know of. If there was another, it would probably have a differentiating name. It's a process you use to produce specifications.

If you use a gherkin-like language, you probably save the specifications in .feature files.

You can write specs.
You can write .feature files.

You write each of them, ideally, shortly before you write the code that will make the specification pass (when run as a test).  Writing the behavior-based test is a collaborative, exploratory-thinking exercise. It precedes coding. Heck, it generally precedes scheduling code to be written. BDD describes the collaboration and conversation and the process, the files are calls "specs" or "specifications" or "feature files."

BDD is to spec file as factory is to car.  You're not out driving your factories, you drive a car.

The specs (or feature files) are the residue from having done BDD.

In some cases, feature files are written without any BDD being done at all. You might write the code, and then write some specs (feature files) afterward to use as integration tests or system tests. You might even feel free to call them "gherkin tests" or "integration tests" or even "story tests" -- I'm not here to judge you.

But you are not writing the BDDs.

When you say you are going to "write the BDDs" you are using the words entirely wrong, and with a very puzzling plural.

You're going to sound goofy around anyone who actually uses BDD as a process.

You are not going to sound like a Behavior-Driven Development professional. You will sound like you picked up the acronym from a blog post and don't know how to use it.

I don't want that for you.

I suggest that you "talk the talkings right so your soundings aren't strange" by dropping "BDDs" from your vocabulary.

Nobody wants to sound like a software hick.

Not that there's anything wrong with real hicks. Some of my best friends are hicks. I used to be a minor-league hick myself. I'm not judging you, here.