The Disco Blog Welcome Guest | Login or Register

Stories are a hip mechanism for clearly communicating intent– as Scott Ambler documented on his Agile Modeling site, stories are a

high-level definition of a requirement, containing just enough information so that the developers can produce a reasonable estimate of the effort to implement it.

What’s more, Dan North builds upon stories and defines them as

the scope of the feature along with its acceptance criteria

The beauty of stories, of course, is that copasetic customers (or domain experts, business analysts, etc) can write them– if they write them according to Dan North’s template, in which a story is essentially a series of scenarios, which read as:

• given some context
• when something happens
• then something else should happen

then these scenarios (which make up a story) form a hip way to validate that what development is building actually meets a customer’s needs.

For instance, because it’s your bag, imagine a game of Blackjack, which, of course, is a simple game of cards adding up to 21. That is, each player is given two cards to start and subsequently can ask for more in an attempt to get to (or as close to) 21 without exceeding it. Essentially the player with the highest score (which isn’t greater than 21) wins the game, man.

In this case, imagine the customer is the casino (in which case, every scenario yields a bogue win for the dealer) or more specifically a blackjack dealer. The dealer could write a hip story with two simple scenarios as follows:

Story: blackjack
    scenario tie game when cards are dealt but dealer gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets an ace and you get a 10
      then the dealer should win
    scenario tie game when cards are dealt but player gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets a 10 and you get an Ace
      then the player should win

Using the latest and greatest hip incarnation of easyb, one can easily (did you really think I’d use a different adjective, man?) create a template that looks like this:

scenario "tie game when cards are dealt but dealer gets higher card", {
 given "a game a blackjack game and both players have a score of 10", {}
 when "the dealer gets an Ace and you get a 10", {}
 then "the dealer should win", {}
}

scenario "tie game when cards are dealt but player gets higher card", {
  given "a game a blackjack game and both players have a score of 10", {}
  when "the dealer gets a 10 and you get an Ace", {}
  then "the player should win", {}
}

As you can see, this copasetic code demonstrates two scenarios and would conceivably reside in a file named something like BlackjackStory.groovy– you’d of course need to fill in the business logic to verify the intended behavior. For example, the first scenario could be fulfilled as follows:

scenario "tie game when cards are dealt but dealer gets higher card", {

 given "a game a blackjack game and both players have a score of 10", {
  player = new Hand(Card.FIVE, Card.FIVE)
  dealer = new Hand(Card.TWO, Card.EIGHT)
  game = new Game(player, dealer)
 }

 when "the dealer gets an Ace and you get a 10", {
  dealer.hit(Card.ACE)
  player.hit(Card.TEN)
 }

 then "the dealer should win", {
  ensure(game.status()){
   isEqualToloss
  }
 }
}

You can then execute this story via Ant with easyb.

 <target name="behaviors" depends="unit-test">
  <taskdef name="easyb" classname="org.disco.easyb.ant.SpecificationRunnerTask">
   <classpath>
    <fileset dir="lib">
     <include name="**/*.jar"/>
    </fileset>
   </classpath>
  </taskdef>

 <easyb failureProperty="easyb.failed">
  <classpath>
    <path refid="build.classpath" />
    <pathelement path="target/classes" />
  </classpath>

  <report location="target/story.txt" format="txtstory" />
   <behaviors dir="behavior">
    <include name="**/*Story.groovy" />
   </behaviors>
 </easyb>

 <fail if="easyb.failed" message="easyb reported a failure"/>

</target>

The most hip part of this whole groovy thing is that after successfully invoking the behaviors target via Ant, you’ll get a story printed (in my case target/story.txt) that looks like this:

9 behavior steps executed successfully
  Story: blackjack
    scenario tie game when cards are dealt but dealer gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets an Ace and you get a 10
      then the dealer should win
    scenario tie game when cards are dealt but player gets higher card
      given a game a blackjack game and both players have a score of 10
      when the dealer gets a 10 and you get an Ace
      then the player should win

In this Age of Aquarius, anyone (like customers, management, dance partners) can read that output and get a warm fuzzy feeling that their requirements are actually being coded! What’s more, if something breaks, the output will indicate a failure. Can you dig it?

Stories are hip. Stories are cool. Stories are easy with easyb, man!

Trackback this Post | Feed on comments to this Post