I have championed of the concept of Behavior Driven Development for several years, spanning a few different employers, during my testing career. In that time, I've made a few discoveries about BDD, and the broader software development community's relationship to it, that have really been bothering me, lately. So, I thought I'd take a moment while I'm on hiatus from *Lessons Learned*, to share my findings with you all.

The first lesson, and perhaps the most important, is that people don't really understand what it is, or what it's for. Most folks equate BDD with Cucumber itself, confusing a tool for a methodology. Everyone equates Cucumber with acceptance testing, confusing collaborative design with test automation. And, as a result of all of this, BDD and its tools have largely been either ignored, or badly misused.

In the startup world, where I work, collaboration and negotiation are the single most important aspects of any software development project. Small development teams cannot afford *not* to stay connected with the needs of the business itself, and the people driving the project. In my view, this makes BDD, and its associated toolsets, an essential component for success, since it enables clear and definite understanding between technical and non-technical team members about what promises the software is meant to keep.

But because Cucumber and Behave are technical tools, and because they look alot like test automation tools, and because nobody is teaching the methodology, the product managers and owners that I've known won't even talk about BDD, let alone even consider using something like Gherkin, as a documentation tool. 

I've had better luck approaching some development team leads. Particularly in environments where product managers are not present (surprising, perhaps, but this is a commonplace reality in the startup world). It's a risky venture, to be sure. But with a little patience and good coaching, it's not difficult to help the tech leads on a team see the benefit. Especially when they are being pressed to satisfy many of the demands put on product managers. Namely, negotiating and documenting feature design and requirement specification.

The first step of hooking them with the promise of test automation will get you in the door, but you'll have to work quickly and persistently, to re-orient the minds of the dev team and tech lead. Your task is to get them to put themselves in the skin of a user, rather than a developer (the first thing he'll want to know how is to specify SQL connection strings Gherkin).  

To do this, I've been been tutoring my present tech lead in Behavioral Driven Development by insisting on two things: 

First, that we absolutely must write out our scenarios during the planning and refinement sessions for any given feature or sprint. That's been a challenge, to be sure. But it has yielded a number of positive results, both in getting the devs to think more laterally and strategically about the features they're building, and in shrinking the amount of churn between the dev team and the CTO (who sets the product direction, presently). 

And Secondly, I have imposed some conceptual and implementation constraints on the way that we use Gherkin to write our specifications. These "rules of thumb" are not wholly canonical, but I find them extremely powerful for getting devs to really understand what they're being asked to do, and how they're being asked to think.

1. Firstly -- and most importantly -- Gherkin frameworks like Cucumber and Behave are not meant to function as substitutes for proper traditional unit, functional, or integration testing. if you're using Gherkin to test input field validation, for example, then you're testing the wrong stuff. If you want to test that input fields are properly empty when a dialog is displayed, you should be writing javascript (or php, or python, or ruby) unit tests. If you want to test that the dialog or light-box is displaying and disolving correctly, you should be writing functional tests. If you want to test that the data in input fields is being stored properly in the database, you should be writing integration tests. But if you want to test that *you're keeping the promises you make to customers*, then you should be writing Gherkin. Or rather, your Product Manager, your Tester, and You should be working together to write it. 

2. Gherkin specs are not quite product specifications. Rather, they are a description of a user's desire to accomplish a goal (what Product Managers might call a "user journey"). Our challenge, then, is to write down all the promises we make to end users about what they will be able to accomplish with this software. Which is a different task than writing down in detail, all the things that the software is capable of.  

3. Gherkin should not be used to "explain how" the user accomplishes his goal. Unless the test is about a specific step along a path, the specific steps are not needed. Gherkin is not user documentation. It is a document describing a contractual agreement with your business team. In short, Gherkin specs describe the "what" of the scenarios, not the "how". What I tell developers specifically, is to beware of trying to embed the *step definitions* into the scenario assertions.   

4. Gherkin specs should not insist on there being one way to do something. In other words, Gherkin should not simply be telling the programmer what to program. I often joke with developers that they should not be using Gherkin as a "macro language for python". They should be free to code up any solution they want in the application, and in the step definitions, that gets the Scenario to its stated goal. Gherkin should not care, as long as the behavioral end-goal is satisfied.

Ultimately, the goal is to get the team to change the way it relates to a software development project as a whole, and to change the way they think about software design. And I've seen some positive moves in that direction with my current team. We've even done a few feature planning sessions with complete specs already, that have yielded insights into the product that led to important improvements and changes.

But, as with all projects -- especially in an Agile environment -- change and improvmement is a gradual, *incremental* phenomenon. Time will tell whether my broader goal is achievable. But for now, I'm just satisfied to see the team writing clean, coherent, manageable Gherkin specifications.