Rick Barry used the “Granny Shot” to propel himself to seventh on the all-time list for free-throw shooting percentage, but when Shaquille O’Neal was asked to adopt Barry’s strategy as a way to lift his woeful performance at the free throw line, he famously rejected the notion.

“I’d rather shoot 0% than shoot underhand,” Shaq was reported to have said. “I’m too cool for that.”

Sometimes I feel like people say the same thing about Gherkin syntax and by extension behavior-driven-development (BDD).

BDD is unorthodox, a little uncomfortable and the non-technical nature of it might make some feel like less of a programmer. But implemented the right way, it can be extremely effective. With a little effort, it can bridge the communication gap between business and technology divisions by getting both sides to agree on a tested set of features.

But it requires learning Gherkin syntax, which, like the “Granny Shot” can feel a little bit awkward.

Let us assume at some point in the software development process that someone who really knows what features people want needs to talk to someone who can implement the software for it. Facilitating this conversation is where BDD could thrive.

So what is BDD? What is Gherkin? What are you even talking about? Why am I even reading this?

I’m not going to pretend to know why you’re reading this, but if you’re in the business of making software, I hope to get you thinking about the requirements documents your business has created. How have you validated those requirements How often do you validate those requirements? How many of those requirements you assume are working are actually broken?

Executives out there might want to know that for many businesses – perhaps their own – requirements are so poorly defined that often it’s the developer who is deciding how the application should work. It would take too much effort to go back on forth on every little implementation detail. BDD and its defining feature, the Gherkin statement, helps push that responsibility of fully fleshing out a feature up the chain to the business analyst.

Take a look at this application requirement, written in plain english. Perhaps a business analyst has tabbed a new feature for development and writes out some acceptance criteria like the following:

After an executive logs into the application, he or she should be able to select one of the trips in the trip-planner list. Then he or she should see all the details of the trip, including flight departure time and associated hotel reservation.

BDD offers a decent attempt at a solution by trying to take plain old colloquial english and mapping it to something with which machines can better deal. This more rigid form of language is known as Gherkin syntax and it was developed for non-technical stakeholders to be able to communicate technical requirements.

Let’s take a quick look at how the above requirements might be expressed in the context of Gherkin statements:

Scenario: Viewing trip details
  Given a user has logged in with the username "Big Boss Man" and the password "passw0rd!" 
  When the account details page is showing for "Big Boss Man"
  And the user selects item "1" from the trip planner list
  Then the user is taken to the "TripDetailsPage"
  And "Big Boss Man" can verify a flight departure at "10:00 am" leaving from "JFK"

It’s quite easy to imagine what this application might look like and what actions need to be implemented from a technical perspective. There needs to be a login screen, an account details screen and a trip details screen, which are often referred to as pages in the testing world. The development team also needs to seed the database with a test user named “Big Boss Man” as well as flight information that indicates a flight departure from JFK at 10:00 a.m. These things can form a pillar around which to build out the rest of the feature.

To keep it high level, I’m not going to go into details here on how these statements map to actual code. One thing to understand however is that Gherkin statements like the ones above generally go in what are call features files, which live in the codebase itself. The one above might be in a file called viewing_details.feature. The test framework then executes these features files, which have code linked to each statement encapsulating the meaning of the statement. Many times a statement represents an action the user takes when using the application in a web browser. Non-technical users can watch the machine perform these tests in real-time.

A group of .feature files represents documentation of tested features, features that stakeholders really care about. Since these tests are being run regularly in a continuous integration environment, each feature can be validated automatically before and after release.

Despite all these good things, there are a few reasons why BDD hasn’t become standard practice. The most obvious being cost. Hours consumed to developing and maintaining a BDD framework is somewhat easy to quantify. The cost savings of having such a framework in place, takes a deeper level of cost estimation and is perhaps harder for the business to see.

From a technical perspective, changing a developers workflow to incorporate BDD tests represents a significant change. So there has to be buy-in from the development team because, believe it or not, there is a large number of developers working today that don’t care to write tests, especially the BDD ones, which have a distinctly different feedback cadence from unit tests. The issues just start there though and I’ll expound on that in a bit.

BDD also requires a change in workflow for the business analyst. Instead of thinking up some requirements and sending those requirements in plain english to a representative of the technical implementation team, now the business analyst needs to understand somewhat how to map those requirements to Gherkin statements. This does not mean the business analyst needs to actually write the Gherkin statements – although that would help. It just means that a business analyst need to be able to recognize a requirement when it is broken down and described in a set of Gherkin scenarios. In some cases, the business analyst might also need to have access to edit the feature files. There might be a little more back and forth with the representative of the technical implementation team, and this costs money. It is important the Gherkin statements are just right so these statements can satisfy the needs of the test framework as well as making clear the high level business need. A business analyst needs to be able to look at set of Gherkin statements and know what it’s talking about. A developer needs to view requirements as a clear spec.

So that’s why BDD isn’t more popular, you might say. Business analysts and tech team representatives don’t have the time or the drive to support that level of collaboration.

While that may be true, there are definitely other factors involved.

To adopt this framework on a development team means having someone on the team that can actually implement the tests. If no one currently can, this level of automation is dead without someone being properly motivated and just like a career free-throw percentage in the 50s wasn’t enough to get Shaq to start shooting “Granny” style, poor collaboration and letting developers decide how a feature should be behave isn’t enough pain to start speaking Gherkin.

These kinds of tests can differ significantly from typical unit tests. If the tests are browser-based, the environment setup is unique to running tests in browser-based environment. If the browser is hitting a development server, the code might need to be pushed to the cloud before it can be tested. This can represent a costly context switch as developers attempt to implement BDD. Also, before any tests can be written, a developer will have to spend some time even standing up a framework with which other developers can easily add BDD tests.

From an execution standpoint, these types of tests generally take a long time to run and the tests are so high level each one isn’t specifically tied a pull request. During a CI run, if a test breaks, it’s not always clear which changes were responsible for the failure. There needs to be a process in place for figuring out who is going to do the work to fix the failing feature. Someone has to be assigned this task and it represents yet another costly context switch and yet another item for the technology team to track.

Until the technical implementation team is able to figure out these details, it’s impractical to adopt this framework.

BDD often represents a rearchitecting of tech and business workflows. One of the most difficult things in business is to get people who are used to doing things one way to change, especially when that change feels a little funny. It then becomes reason not to adopt a system that produces an accessible list of tested features. It becomes a reason for being cool with missing free throws.

References

https://www.basketball-reference.com
https://www.businessinsider.com/why-shaq-shaquille-oneal-never-tried-underhand-free-throw-percentage-2017-12