Personal Behavior-Driven Development

by on August 19, 2013 12:07 pm

This year I was fortunate enough to attend the KCDC conference here in lovely Kansas City. One of the sessions I attended was on Behavior-Driven Development. I have attended several BDD sessions before and have enjoyed each one of them, but there was one stated question that set this one apart from the others. After learning of all the benefits of using BDD in one’s practice and becoming excited to start such a wonderful discovery, what happens if you won’t have any frameworks or management buy-in to support your mission?

As the BDD sessions indicate, frameworks such as Cucumber and JBehave gives the Agile team a way to create testing scenarios in a plain text format. So how do you set out on your own and what BDD principals can you implement on a personal development level?

Since BDD is an extension of Test-Driven Development, is it easy enough to use the principles and keywords of BDD down to the unit test level. Bringing BDD down to this level starts with following the naming template Dan North recommends for unit test method names.

At some point or another, we have all used the test class generator in Eclipse to save some time. It does give you a pre-populated class that prepends the word test in front of all visible method names, but is that time-saving or helpful in the long term? Is it easy to tell what testCalculateCost() tests for? You will eventually add more test cases for that particular method. How will you differentiate the method names for each additional test case?

Dan North recommends using sentences based on behaviors to describe the test. The test method testCalculateCost() would become testShouldFailForMissingBillingDate(). Dan also recommends using the word “behaviour” in favor of the notorious keyword “test” when describing what to test next. It is more natural to determine the behaviours of calculateCost() and to compare the next behavior to the existing behaviors to eliminate the gaps. The next natural behavior to test for may be the behavior of a missing due date with testShouldFailForMissingBillingDueDate().

Along with using the naming conventions suggested by Dan North, the session demonstrated how to organize the behavioral test class to mimic a BDD test scenario. As with BDD scenarios written for JBehave to parse, given/when/then BDD keywords are used to help construct and organize what is needed in the test class. These BDD keywords replace the arrange/act/assert keywords commonly used in plain unit tests.

Unit to BDD test keyword translation:

Unit Test Keyword → BDD Keyword
Arrange/Assemble → Given
Act → When
Assert → Then

While developers who are not on an Agile team can still use this style of writing behavioral tests, not starting with a user story can add to the learning curve. It is easier to translate a user story that contains the same structure as the finished personal BDD tests than a bullet point list of requirements. We will use a very basic user story along with a couple BDD test scenarios to show how similar the user story, BDD test case, and personal BDD test class are.


We are working on a user story to add functionality to a Sudoku game to allow the user to verify if the numbers picked are correct during an in-progress game. Following BDD practices, the game functionality has not yet been implemented.

Story: Verify the board.

In order to verify the picked numbers
As a game player
I want the game to verify my picked numbers.

A BDD framework would accept something like this:

Scenario 1: A player who wants to know if they have incorrect numbers
Given a player who has a game in-progress
    When the board has all correct numbers
the player verifies the board
Then the board should be returned verified as correct

Scenario 2: A player who wants to know if they have incorrect numbers
Given a player who has a game in-progress
        and the board has all correct numbers
When the player picks an incorrect number
Then the board should be returned verified as incorrect
     and the incorrect number will be flagged as incorrect

Since we are back from the conference and in our BDD-less world, we will have to use our own creative process to fill in the guts of our personal BDD test class. At first, testing with a behavioral approach and not producing tests based on method names of the test fixture will be a little more difficult and time consuming, until this way of thinking is learned. It wasn’t an easy tread transitioning to a TDD world, but at least this will be an evolutionary step.

With this, we can start building our new personal BDD test class to test the behaviors of the verify method using JUnit 4.

Following what Dan North recommends, we can use the name SudokuBoardServiceSolveBehavior as our test class.

public class SudokuBoardServiceVerifyBehavior {

As we fill out our test class using personal BDD, we will use the structure and the keywords of
given/when/then similar to what is in Scenario 1 and 2. While we won’t have the scenarios, they do help conceptualize the structure and organization of the test class.

The keyword given will be used for the test fixture generation methods. The method name will help define the test fixture and the scope of the acceptance tests. The given method will be annotated with JUnit’s @Before annotation and will be in the shared data. In our scenario, we want to start with a board partially filled with correct numbers.

public class SudokuBoardServiceVerifyBehavior {

	public void givenCorrectBoardNumbers() throws Exception {
    		//stub the board
   	 	board = TestBoardFactory.createPartialBoardWithCorrectNumberes();
    		//setup the service
    		service = new SudokuBoardService();

Next, the when methods contain the executable steps to take on the test fixture. Depending on the number of different behaviors to test, you may have several when methods for the single given method.  Each when can cover a BDD test scenario.  The when methods will be annotated with JUnit’s @Test.

public class SudokuBoardServiceVerifyBehavior {
	public void whenUserPicksCorrectNumber() {
   	 	//pick correct number

	public void whenUserSelectsInCorrectNumber() {
   	 	//pick incorrect number

Now we have the behaviors being performed on the test fixture. The last step is to find out what happened. Did we implement the requirements as expected? We will soon find out with the then methods. The more complicated the system, the more thens you will have as there will be more assertions to make about a behavior. For clarity and descriptiveness, you will have one assert per then. When you find that a unit test fails, you will know immediately and understand why the test failed. The method name will describe what we are asserting for. The when methods will be the ones responsible for passing control their respective then outcomes.

public class SudokuBoardServiceVerifyBehavior {
	private SudokuBoard board = null;
    	private SudokuBoardService service = null;
	private static int POS_X = 0;
	private static int POS_Y = 0;

	public void givenCorrectBoardAndCorrectNumbers() throws Exception {
    		//stub the board
   	 	board = TestBoardFactory.createPartialBoard();
    		//setup the service
    		service = new SudokuBoardService();

	public void whenUserSelectsCorrectNumber() {
   	 	//pick correct number

	public void whenUserSelectsInCorrectNumber() {
   	 	//pick incorrect number

	private void thenTheBoardIsVerifiedAsCorrect() {

	private void thenTheBoardIsVerifiedAsInCorrect() {

	private void thenTheIncorrectNumberIsFlaggedAsIncorrect() {

So what just happened here in order to bring BDD to the personal level?

You just became the framework replacement. You just translated the set of business requirements into unit tests. The only difference is that you used JUnit annotations instead of the set of annotations from Cucumber or JBehave. While these behavioral tests in no way compare to the value of what a full BDD infrastructure provides, we were able to introduce BDD principles and structure to a personal level. Personal BDD still provides the benefits of using BDD principles to focus on behaviors that directly contribute to business outcomes. Personal BDD will aid in writing unit tests that produce communicable evidence to the developers that the behavioral aspects of the system are working. Testing becomes more descriptive with better test class and method naming conventions.

To stay inline with BDD principles, the tests are still nicely automatable. Once all the tests pass, there will be a fully implemented business function protected with functional tests.
– John Hoestje,

  • Share:

3 Responses to “Personal Behavior-Driven Development”

  1. I like this translation. It reinforces the fact that development strategies can almost always be implemented without specialized frameworks. Just have to be creative!

  2. […] Testing: Defining the right “Unit”Blog: A Dungeon Master’s Guide to SCRUMBlog: Personal Behavior-Driven DevelopmentBlog: Our checklist for improving mobile […]

Leave a Reply

Things Twitter is Talking About
  • DYK? When we share/RT/blog/etc, it doesn't mean that Keyhole endorses it - we just like variety of opinions! Info:
    April 19, 2014 at 3:01 PM
  • A huge welcome to Justin Graber who joined the Keyhole team this week!
    April 18, 2014 at 3:25 PM
  • Pssst... @kc_dc early bird pricing ends on Sunday. Shoot us a note if you want to save 10% off of your ticket with our sponsor promo code!
    April 18, 2014 at 2:49 PM
  • Join our team! Looking for a developer w/ advanced #JavaScript & #NodeJS experience (& love of tech variety). Info:
    April 18, 2014 at 11:21 AM
  • .@befamous has huge potential to make HTML5/JS/CSS web pages feel as native apps. Here's our inital tech takeaways -
    April 18, 2014 at 9:50 AM
  • Why to use AngularUI Router instead of ngRoute -
    April 17, 2014 at 7:55 PM
  • RT @joemccann: Total Number of GitHub Repositories by Programming Language
    April 17, 2014 at 4:25 PM
  • JSF + AngularJS = AngularFaces? // Interesting insight. Thoughts?
    April 17, 2014 at 3:45 PM
  • RT @MikeGelphman: Great news, guys: @TobiasRush founder of @eyeverify is our latest @MobileMidwest speaker addition
    April 17, 2014 at 1:35 PM
  • .@befamous was released publicly 4/10 & we've been tinkering with it since. What we've learned so far via a POC app -
    April 17, 2014 at 8:33 AM
  •' main idea is for HTML5/JS/CSS web pages to feel like native mobile apps. So, @zachagardner tried it out -
    April 15, 2014 at 6:40 PM
  • @JKFeldkamp Thanks for your RT! Such a neat technology. We're so excited @zachagardner is getting involved. Have a great day!
    April 15, 2014 at 4:00 PM
  • .@zachagardner has been tinkering with (@befamous) released 4/10. What he's learned so far with a POC app -
    April 15, 2014 at 2:29 PM
  • Tutorial: create #RabbitMQ Template to send msg to an exchange & listen for msgs with a routing key pattern -
    April 11, 2014 at 10:02 AM
  • There's a great #KC conference coming up on April 23rd - @KCITP's Mobile Midwest Shift into a “Mobile First” mindset!
    April 10, 2014 at 3:59 PM
  • Interesting - 6 #programming paradigms that change how u think about coding: & its discussion:
    April 10, 2014 at 10:11 AM
  • DYK? When we share/RT/blog/etc, it doesn't mean that Keyhole endorses it - we just like variety of opinions! Info:
    April 9, 2014 at 2:13 PM
  • Developers, need a chuckle? 12 Problems Only Programmers Understand - #funny
    April 9, 2014 at 2:00 PM
  • Immediately looking to add to our team a Sr. C# developer with knowledge of #NodeJS, #Marionette & #MongoDB. Details:
    April 9, 2014 at 1:27 PM
  • A huge welcome to Vince Pendergrass who joins the Keyhole team this week!
    April 8, 2014 at 2:37 PM