ADS specializes in using Ruby on Rails to build advanced, scalable, database-backed web sites for organizations of all sizes. Find out more at our website.

The first tutorial of the day, “A Half-day of Behavior-driven Development on Rails,” was great. Led by David Chelimsky, Aslak Hellesoy, and Dan North, the first half of the tutorial discussed Behavior Driven Development. In short, we were instructed on:

• What problem BDD solves
• Programming from the outside-in
• Peoples and roles
• Two audiences
• BDD background

BDD, per our instructors, helps developers write software that matters. What is meant by that is that customers who will use the software will be more involved in the development process, and due to the way that they are engaged, will better understand what they are getting and how it works. In addition, by asking questions such as “What should this application do?” and “What does this part of the app do?” both the developers and the stakeholders (the audiences) better understand what the desired outcome is. That last point was stressed quite a bit. Scope creep was defined as a disconnect between how the development team and the customer define “done.” An upfront definition and agreement on just what “done” means is imperative to the success of every project.

Programming from the outside-in was an interesting point. Sponsors (or customers if you prefer) talk about what the app does, not how it works. These descriptions of functionality then become the technical specification, which in turn becomes a series of rspec tests. As rugby was the talk of the day, a rugby cup application was the example. A few of the rspec model tests included:

• “should report correct number of max_teams”
• “should create 2 rounds for 4 teams”
• “should create first round with 4 matches for 8 teams”
• “should not allow changing max teams after creation”

Now those are tests that a customer can understand without knowing any code! Plain English - life is good. Notice too that the tests don’t sound like how the application works but rather what it does, or should do. You could manually QA these as well (which some of our clients like to help out with).

The second half of the tutorial was coding. You can download all of the code we used at:

svn co svn://rubyforge.org/var/svn/rspec/branches/railsconfeu2007

One item that I learned about today which I didn’t know about was how rspec does integration testing. True to the BDD technique, rspec integration testing uses a Story format. The story that we were testing was planning a cup. Download the files from subversion and navigate to trunk -> stories -> plan_cup.rb. Very cool.

For more information on RSpec, check out the website, or see the RSpec Rails documentation for Rails specific RSpec goodness.

Check out the pics on Flickr.

Random Goodness

• JRuby 1.1 RC2 Released
• acts_as_conference registration going strong
• JRuby Core Team Member Charles Nutter Interviewed for Rails For All