What is Behavior-Driven Development?

This week’s topic has to do with behavior-driven development, which a strategy of software development that focuses on the communicating narrative between developers so as to ensure that all members understand the specifications and other requirements of a program. I found an insightful article at the following website: https://airbrake.io/blog/software-design/behavior-driven-development, which is one of a few in a series explaining different development techniques that work together as part of the software development life cycle.

As explained in the article, behavior-driven development, or BDD, works hand-in-hand with other strategies, such as test-driven development, which entails the execution of a failing test and then subsequently writing a minimum amount of code in order to pass the test. BDD becomes different from this technique when it relies more on the desired behavior of the program, rather than simply writing initially failing tests for all parts of the program, as utilized with test-driven development. BDD defines behavior specifications with user stories that outline various scenarios for the program to be executed or tested. These stories take on a narrative tone that states who and what are involved in each scenario, as well as the conditions that must be met in order for the scenarios to be successfully implemented. By using a common language understood and easily communicated by everyone on a development team, members can easily collaborate to define these specifications and perform tests based on the definitions given with the user stories.

This topic stuck out to me because it somewhat combined what I have been learning in both my Software Design and Software Testing courses this semester. This post discusses different methods of designing programs and their tests, and I thought that BDD clearly incorporated both, with the description of designing the behavior specifications to be met, as well as the concept of testing these specifications. We’ve somewhat been starting to take on both of these roles in the classroom by determining the purpose and desired functions of our programs, and then performing tests to ensure that the functions are working successfully. While we haven’t written out user stories to more specifically outline the behaviors, I think that this process is more implicit for us at this point.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this:
search previous next tag category expand menu location phone mail time cart zoom edit close