Hi Michael

It is not dumb at all. I was in the same point a while ago. And although it seems magic, they are executable tests, actually.

The idea is simple, there is a pattern matcher that given a sentence, it executes it. Something like:

if sentence = "there is 1 orc" then add 1 orc
if sentence = "there should be 1 orc" then expect orcsCount toBe 1

And so on. There are libraries that do the pattern match for you, using RegularExpressions, or even simpler structures to get arguments. Something like:

given "there is {number} {string}" (count, type) -> add 1 orc
given "there should be {number} {string}" (expected, type) -> expect countOf(type) toBe expected

It seems sometimes overkilling, but it has good reasons to exist:

1. Ease communication with Product roles (they can read them as English)
2. Help programmers to create good quality tests

The second is the reason why it exists. Learn testing properly is very hard in agile, and Dan North created it to focus correctly tests. That is why BDD is Behavior because instead of "testing" a piece of code, we focus on one behavior (or example) of the business rules.

Tests should be decoupled from code, easy to read, and focused on business value. BDD helps on all of them, and that is why it is great for training. And later to ease communication.

I hoped it helped, it looks like it would be a good idea to write a post about how to land all of this in actual code. Any language preference?

Thanks!