The Disco Blog Welcome Guest | Login or Register

The easyb code base has been moved to Google code, which has copasetic support for anonymous SVN access (which, unfortunately, didn’t work for QualityLabs). If you want to take a peek at what’s under the hood, simply type:

svn checkout http://easyb.googlecode.com/svn/trunk/ easyb-read-only

We’ve also created a hip easyb users group, so if you have any questions, comments, or rants, drop us a note!

The Framework for Integrated Tests serves as an copasetic mechanism for bridging the gap between those that write requirements and those that turn those requirements into code– the beauty of defining business rules in tabular format (either through HTML, Word documents, and even Excel files) and auto-magically wiring that data with application code is no Siren song, but an accelerating force for high speed development teams living in the Age of Aquarius. What’s more, combining FIT with a wiki was a brilliant move and the resulting tool, FitNesse, brings together the power of FIT with a collaborative mechanism for building test suites and capturing requirements (and even stories) by leveraging the ubiquity of a browser.

While FitNesse has been leveraged by some, it, in many ways, baby, has suffered from a lack of in depth documentation– indeed, even Mugridge and Cunningham’s hip “Fit for Developing Software: Framework for Integrated Tests” book barely scratched the surface of FitNesse, thus leaving some teams in the dark as to how to effectively employ it. Luckily, with the publication of Gojko Adzic’s “Test Driven .NET Development with FitNesse” any lingering questions developers may have are now answered.

Because it’s his bag, Gojko does an excellent job of taking an application from inception to production, all the while building on technique after technique for defining FIT tables and running them with FitNesse. He does a hip job of making the case for the complementary nature of unit testing (in this case NUnit) and acceptance testing with FitNesse; what’s more, even though the programming domain is .NET, this book peels away enough of the covers of FitNesse (which is, of course, written in Java) to make it useful for anyone looking to employ the tool, man.

If you find yourself curious about FitNesse or are looking for ways to leverage domain experts more effectively, then I highly recommmend picking up a copy of “Test Driven .NET Development with FitNesse“– when you finally set the book down, you’ll find yourself a much smarter person! Dig it?

Well, it’s been an unhipply long time since I’ve done the bag– my apologies.

• Andrew Binstock rounds up the Java IDEs- this hip podcast with my friend Andrew sheds some light on Eclipse and IntelliJ that was news to me, baby.
• Jay Zimmerman on Java application development in ‘08- One more copasetic podcast worth a listen to– Jay is uniquely positioned to surmise on what’s to come.
• On the Effectiveness of Test-first Approach to Programming- my friend Jay sent this my way– note this line: the authors “observed that the minimum quality increased linearly with the number of programmer tests, independent of the development strategy employed.” Excellent– someone has actually proved that tests work!
• Can Dynamic Languages Scale?- Chandler dying had nothing to do with Python, man. Or is global warming really a result of the decline of pirates? Regardless, the TSS thread is always a hip read.
• TDD Anti Patterns- Roy’s the man when it comes to anything related to TDD, baby.
• I’m not tired of Java yet- Neither am I, baby– last I checked, my family was well fed.
• Twin Cities Roundtable on Test-Driven Development- Talkin’ TDD is so disco, baby– be there or be square.

Prognostication is by no means my bag and more often than not, speculative guesses about the future are incorrect– yet, if history has shown anybody anything, it’s that history (when examined in context) is often a good indicator of what’s to come. In fact, things in our hip industry rarely happen over night– by understanding what shaped yesterday, you can often get a handle on what’s coming tomorrow.

For instance, how would anyone have guessed that back in the 70’s disco would survive and flourish into the 21st century? Yet, if you study the trends of today, you can plainly see that disco music is alive and kicking. I’m proud to say that disco is stronger than ever, baby.

Disco music aside, I had the pleasure of speculating on what 2008 holds for the Java platform– in short, if you look at the major aspects of 2007, among other noteworthy matters, you’ll see a clear interest in dynamic languages, fueled by JRuby and Groovy, you’ll see a more open Java, both on the platform itself and the business model surrounding it, and you’ll see that Google is becoming (if not already) a major force shaping Java. Indeed, 2008 is going to be all about dynamic languages, agility, and disco.

Check out JavaWorld’s “The future is now — Java development in 2008” and let me what you think!

I’d also like to thank the following copasetic individuals whose bag of valuable insights regarding all things Java helped shaped the article: Neal Ford, Andres Almiray, Dan Allen, Ted Neward, Scott Stirling, Scott Moore, John Smart, Nate Schutta, Michael Nyika, Venkat Subramaniam, Guillaume Laforge, Scott Delap, Paul Duvall, David Pinkham, Rod Coffin, Andrew Binstock, Ken Brooks, Jay Zimmerman, Paul Julius, Tom Copeland, Navjeet Chabbewal, Jason Rudolph, Chris Judd, Dave Aronson, Cliff Berg, David Bock, and finally Alex Ruiz & Yvonne. Thank you all for being so hip, baby!

The Washington, DC area will be in the groove this coming February as super hip folks like Brian Sletten, Scott Davis, Neal Ford, Andres Almiray, Jeff Brown, Jason Rudolph, Graeme Rocher, Dierk Koenig, Alex Popescu, Scott Leberknight, and Venkat Subramaniam (to name just a few, man!) converge to chew the fat over Groovy, baby! These are some of the smartest people I know; consequently, if you have any interest in Groovy (or dynamic languages in general, man) you should plan on attending.

It promises to be a copasetic time, so if you’re planning on attending, let me know!

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!