Behavior driven development (BDD) has a lot of benefits (less developer time spent context switching, automated regression test suites, etc.), but by far the biggest benefit is what it does for developers tackling daunting problems.
As I started tackling a sprawling problem yesterday, it could have felt overwhelming. But BDD provided a systematic process to isolate subsets of the problem and to break those down into discrete steps. And because of the red-green-refactor discipline, I immediately started receiving positive affirmation.
BDD essentially creates a game wherein the developer sets an achievable goal—by writing the next few specs—and then achieves that goal—by writing the code that makes those specs go green. The goals are discrete, they are measurably achievable, and they naturally lead the developer through the various strata of specificity, so that the depth of a particular problem is gradually discovered:
- I need to be able to do X
- write specs that describe what I will see when I have X
- write the code to make the specs pass
- while writing code, encounter something X needs to know about or do in order to achieve the behavior defined in step 2
- in X’s specs, mock the behavior discovered in step 4 so that X’s specs can pass without that new functionality
- step 4 revealed the next need…plug that into step 1 and repeat the process
BDD is a process that tackles complex problems by breaking them down into discrete sub-problems. It draws the developer on a guided path of discovery about what is needed to solve those sub-problems. It solves each discrete problem along the way. And it rewards the developer at every step with the satisfaction of goal achieved. As far as “gameification” of work goes, that is hard to beat.