We'll respond shortly.
Let’s talk about cargo culting.
When I started doing BDD, I cargo-culted it. I basically had no idea what I was doing. I worked at a company that had never done it. I worked with developers who had never tried it. I read blogs posts and watched screencasts, and I thought I got it. I didn’t. I cargo culted it, and I got it wrong. Result? Pain.
Lots of developers have had a similar experience, and they reached a crossroads: fight or flight. I fought the pain. Did you?
Let’s talk about history.
I want a museum of code. I want to see the first program that had a test written in it. Maybe it’s in C. Algol. Lisp. Maybe it’s a punchcard. Who knows?
Testing started as a movement with Smalltalk. They created SUnit. Smalltalk Unit. It worked. They unit tested their code. That was the easiest type of test to write. It didn’t require any fancy tooling or extra frameworks. Load up an object, assert on it.
Over the years, higher levels of testing emerged. Functional tests, integration tests, acceptance tests. Tooling grew up along side these higher level tests to make them possible.
What was Agile doing?
Agile had conversations. They were talking to their product owners, asking them questions, drawing out concrete examples. Today we call this “Specification By Example.”
Dan North came along. He said TDD was backwards. Why do we starting writing tests at the unit level? We have this process of specification by example with our product owners, and our development process doesn’t line up with that. What if we turned our development process on its head and TDD’ed outside-in? What if that converastion was truly a launching-point into our development process, what if that conversation was a spec that told us when we were done?
BDD is about drawing a line from a conversation with a product owner through the development of a feature and back to the product owner. BDD tools make this possible.
If your BDD process doesn’t start with a conversation with your product owner, you will feel pain.