Behaviorism is a fascinating subject and an immensely powerful tool when applied correctly.  Just ask any informed educator or parent — or perhaps that coworker who appears to have it all under control — and you might discover a new, sharp arrow for your quiver of workplace magic tricks.  If you’re unfamiliar with the concept (behaviorism, that is—not magic), feel free to use your favorite dictionary app to get up to speed.  Go ahead, I’ll wait.

A CONCISE ARGUMENT

At the heart of behaviorism is the notion that environment has a profound effect on human behavior.  For example, one might be more likely to respond in frustration when surrounded by a group of frustrated individuals.  Similarly, when expected to code a feature, an environment of ambiguity surrounding the requirements for said feature might result in a longer-than-expected development cycle.  

Common sense and life experience tells us that both of these example scenarios are likely true, but common sense and life experience mean little (in a scientific context) because they’re both quite subjective.  The real golden kernel of behaviorism is that it provides a way for hypotheses (i.e. expected outcomes) to be more easily testable.

The Connection to User Stories and Industry Practice

Standard form for requirements-gathering, user stories are seminal for documenting and communicating the substance of a requirement in business-centric language.  However, while a user story clearly outlines what’s needed from a business point of view, it lacks a certain context.  In my experience, a user story (no matter how well it is phrased) is at best a way of documenting a business need.  However, when developing said business need, a developer may not know where to start.  Certainly, the best user stories have acceptance criteria attached, but I’m referring to something even more granular—behavioral characteristics leading to a more well-defined functional test. 

An Analogy

Providing a user story (without a behavior-driven test scenario) to a developer with the expectation that a beautifully-crafted word processor will result could be compared to giving a wet newspaper to an origami artist with the expectation that a swan figurine will result.  If you’re thinking, “Well, the artist could make the best of the situation and use papier-mâché to craft the swan” you are to be commended for thinking creatively.  However, if the original requirement was for an origami swan, a papier-mâché swan won’t fit the bill.  What’s the point?

The fewer the expectations and the more open-ended the ask, the greater the likelihood for unmet expectations, deviations from previously agreed-upon standards, and ultimately, an unhappy client.  

Therefore, utilizing behavior-driven development principles which clearly delineate the intended function of a feature helps to close an additional (potential) gap in the development cycle.  The end result might be fewer iterations, fewer wasted resources, a greater sense of accomplishment on the part of the team (i.e. a morale boost), and a cost savings to the client.

CONCLUSION

Behavior-driven development, Cucumber syntax, Gherkin, etc. are not substitutes for any of the following:

  • Inter-departmental collaboration

  • Requirements elicitation/gathering/trawling

  • User stories

  • Scrum

  • Any industry “best practice”

However, when added to an existing, healthy development framework and testing practice, behavior-driven development (BDD) can prove an excellent augmentation.

 

Given a need for greater functional clarity

When behavior-driven development principles are applied

Then your practice might just take a turn for the better

 

QUESTIONS FOR REFLECTION

  1. Does your firm use BDD to augment the traditional user story/requirements-gathering framework?

  2. How has incorporating BDD helped improve your personal (or firm’s) practice?

  3. Why might BDD better facilitate an automated testing framework?

 

Join the Conversation

About the Author