Tumble dried BDD from Studio Pragmatists

On the 18th of May, 2010, the very new tumbler-glass project by Studio Pragmatists uploaded Tumbler 0.2.1 to Maven.  Having recently written about JBehave I found myself really liking the concept of behavior driven development.  So I decided to write a similar article about Tumbler. If you want the project code its available in my example project.

4 hour time box in 20 minutes!

Once again I decided to time box the work to 4 hours.  This time though the whole process only took about 20 minutes.  The product owner and testers produce a story file.  The Tumbler format allows for multiple stories each containing scenarios, so its possible to cover a complex set of requirements in one file.  This allows for flexibility when breaking down the work into tasks.  As per the usual behavior driven approach, a scenario contains the Given, When and Then sections which describe the behavior. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Bad or Good? Behavior Driven Development within Scrum.

I wanted to explore the possibility of using JBehave to formalise scrums definition of done. The idea being to encapsulate a definition of done as a JBehave scenario. So in true scrum style I decided to timebox 4 hours of work dedicated to JBehave.

From a scrum point of view BDD can be used to turn the definition of done into a test artifact. The team produces scenarios for each task. With JBehave a scenario file describes the required behavior and test steps it will need to pass to be considered done. I.e Given some prerequisites, perform some action and expect some results. See the JBehave project for more detail as this is only a simple example. Continue reading

Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

Hamcrest Collection Matching with Junit 4.8

Sometime back I wrote about some testing anti-patterns.  Recently I came back to the project and made some trivial changes.  I fixed a bug upgraded spring and junit and migrated the test assertions to hamcrest fluid style.  The full project is available on git.

I find hamcrest to be a much cleaner way of writing assertions.  This test demonstrates the use of its fluid interface with some simple collection assertions.  There are newer versions of Hamcrest and the collection package may have moved into core, but the version I use here (1.0) was available on maven.  Note the integration with Junit.  The hasItem and hasItems methods are sourced from Junit 4.8.1.

package org.testpatterns.hamcrestexamples;

import java.util.Arrays;
import org.junit.Test;
import static org.hamcrest.collection.IsArrayContaining.hasItemInArray;
import static org.junit.matchers.JUnitMatchers.*;
import static org.junit.Assert.assertThat;

public class CollectionExamples {

  //Hamcrest with Collections and Arrays:
  static final String[] array = { "A", "B", "C" };
  static final List<String> list = Arrays.asList(array);

  @Test
  public void oneThingInArray () {
    assertThat(array, hasItemInArray("A"));
  }

  @Test
  public void arrayOfItemsInList () {
  String[] expected = { "A", "B", "C" };
    assertThat(list, hasItems(expected));
  }

  @Test
  public void itemInAList () {
    assertThat(list, hasItem("A"));
  }

  @Test
  public void itemsInAList () {
    assertThat(list, hasItems("A", "C"));
  }

}
Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)

KeySet v EntrySet code tidy

Its astounding how often I find maps being used like this.

for(String name: names.keySet()) {
    mymap.put(mymap.get(name),name);
}

Its inefficient because you have to fetch the keys and perform a lookup in the map with the key.

Instead using the EntrySet you can get all the keys and values in one hit. This saves having to perform the map lookup.

for (Entry<String, String> entry : entrySet) {
    mymap.put(entry.getValue(),entry.getKey());
}
Digg This
Reddit This
Stumble Now!
Buzz This
Vote on DZone
Share on Facebook
Bookmark this on Delicious
Kick It on DotNetKicks.com
Shout it
Share on LinkedIn
Bookmark this on Technorati
Post on Twitter
Google Buzz (aka. Google Reader)