Lesson Tuesday

As our projects get more complex, we need to break our code down into a series of smaller, more manageable programming tasks. However, it's absolutely essential we do this - otherwise, we'll be overwhelmed! Think of it as being similar to an architect designing a building. The architect's to do list won't just have one item that reads "Design building." Instead, the planning is broken up into many smaller tasks, each with the end user in mind. For instance, where should windows be placed to let in the most light? Where should passageways and doorways to be placed to facilitate movement through the building?

We have a name for this process when we are writing code: Behavior-Driven Development (or BDD).

In BDD, rather than thinking about the code first, the focus begins on the behaviors that we want to see in our final application. We identify what the program should do before determining how to make it do it. Just as an architect determines how people will move through and interact with a building before it's ever built, we need to do the same thing before we build out our applications.

To practice this, we'll imagine that a person born on February 29th has hired us to build an application. She would like to determine if any given year is a leap year (meaning it's a birthday year for her). Here's a finished example of what she'd like: Leap year detector.

Before we think about the programmatic elements, what should a leap year program do? Let's break this down into the smallest elements possible. In this way, we'll also make our lives easier as coders and we won't be overwhelmed by the scope of our project.

On the most basic level, our program will accept a year as an input and answer true or false to the question: is this year a leap year? Let's think of all of the possibilities we might get from a user and what the correct response should be for them.

Timeanddate.com lists three criteria to determine if a year is a leap year:

  • The year is evenly divisible by 4;
  • If the year can be evenly divided by 100, it is NOT a leap year, unless;
  • The year is also evenly divisible by 400. Then it is a leap year.

Therefore, each time a user offers a year to evaluate, we will ultimately need to test the value against each of the leap year rules.

In BDD, our next step is to generate examples of these rules. These examples are also known as specifications or specs. We can create a table that helps us sort out the details of the specifications for each rule using the following pieces of information:

  • The behavior that we'll need to write code to handle
  • A sample of input that would demonstrate the behavior
  • The expected output we'd get when the code is working correctly

Leap Year Input-Output Grid

Let's look at another example of specs organized on a table showing behavior, input and output:

Title Case

In this example, we want to build an application that will take a user's string of words and convert them to title case - capitalizing letters like we'd find in a book title. There are a few more rules for creating title cased words from strings than Leap Year. Let's brainstorm the first several:

BDD Table for Title Case

As we did with the leap year application, we choose the simplest first - one word gets capitalized - beowulf becomes Beowulf and go to the most complex. And as always, we may think of additional behaviors along the way. For instance, what if a user enters nothing? What if a user enters iPod or McDuff? Remember, let your brain keep brainstorming by adding new behaviors to your list but always stay focused on one specification at a time.

Lesson 1 of 10
Last updated July 2, 2020