About Keyhole Software

Keyhole is a midwest-based consulting firm with a tight-knit technical team. We work primarily with Java, JavaScript and .NET technologies, specializing in application development. We love the challenge that comes in consulting and blog often regarding some of the technical situations and technologies we face.

Personal Behavior-Driven Development

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.

Example

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 {

	@Before
	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 {
	….
	@Test
	public void whenUserPicksCorrectNumber() {
   	 	//pick correct number
   	 	board.setNumber(POS_X,POS_Y,5);
    	}

    @Test
	public void whenUserSelectsInCorrectNumber() {
   	 	//pick incorrect number
   	 	board.setNumber(POS_X,POS_Y,4);
	}
}

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;

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

	@Test
	public void whenUserSelectsCorrectNumber() {
   	 	//pick correct number
   	 	board.setNumber(POS_X,POS_Y,5);
    		thenTheBoardIsVerifiedAsCorrect();
	}

	@Test
	public void whenUserSelectsInCorrectNumber() {
   	 	//pick incorrect number
   		board.setNumber(POS_X,POS_Y,4);
 		thenTheBoardIsVerifiedAsInCorrect();
    		theTheIncorrectNumberIsFlaggedAsIncorrect();
	}

	private void thenTheBoardIsVerifiedAsCorrect() {
   		service.verify(board);
   		assertTrue(board.isCorrect());
	}

	private void thenTheBoardIsVerifiedAsInCorrect() {
   		service.verify(board);
   		assertFalse(board.isCorrect());
	}

	private void thenTheIncorrectNumberIsFlaggedAsIncorrect() {
   		assertTrue(board.getNumber(POS_X,POS_Y).isCorrect());
	}
}

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.
 

Reference: Personal Behavior-Driven Development from our JCG partner John Hoestje at the Keyhole Software blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

One Response to "Personal Behavior-Driven Development"

  1. Diana says:

    Great post!
    More information on BDD you can find also here http://www.binary-studio.com/2014/4/25/bdd-specflow-watin-part-i

Leave a Reply


+ four = 8



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close