first lets get a copy of rails 3 going

# make sure you have gem bundler and rack installed:
sudo gem install bundler rack

# clone of edge rails
git clone git://github.com/rails/rails.git

# generate a new app:
ruby rails/railties/bin/rails my_app
cd my_app

generate a new app:

ruby rails/railties/bin/rails my_app
cd my_app

now we have to edit our ./Gemfile with some required gems that have not been released yet.

git "git://github.com/rails/arel.git"
gem "rails", :git => "git://github.com/rails/rails.git"

then use the new gem bundler to bundle additional required gems:

gem bundle

now script/server, script/console, script/generate, etc.. should be available as normal

Configuration

I have chosen to replace some of the default configurations with my own such as changing fixtures to factories, there is a great lightweight version of factory_girl by Stephen Celis written in about 30 LOC. So we will use one of the new configurations available to us to prevent the default generators from producing fixtures automatically, also prevent the scaffold generator from creating controller layouts as I remove them anyway.

place within config/application.rb

config.generators do |g|
g.template_engine :erb, :layout => false
g.test_framework  :test_unit, :fixture => false
end

to be continued ..

In my attempt at progressing my knowledge around the topic I decided to document my discoveries here so that others may benefit.

What is it?

Behavior driven development attempts to take the traditional approach we take to doing things and turn it on its head. Rather then thinking from the bottom we think from the top down. Who does this unit of functionality benefit? why does it benefit them? and how do they interact with it?

Answering these questions will help us to determine if a feature is needed and at what point in time.

How do I get started?

While lots of articles exist on setting up Cucumber and and Rspec and many examples exist for the cucumber feature syntax, none really guide you in the direction of where to begin. Ive found myself hung up running in circles, asking questions until I’m blue in the face with not one line of code written.

• What feature do I start first? possibly authentication?
• What constitutes a feature? “Manage users”? or just “Creating a user”?

lets try to answer some of these with the opinions I have developed.

What feature do I start first?

The answer to this question is almost so incredibly easy that you bypass it completely. Think about the problem BDD is meant to solve, we want to create “software that matters”.  We want to spend our time working on the features that matter most, those that will ultimately make you money. So lets answer this question what is the primary goal of your product?

Lets take a hypothetical project, an issue tracker for example. Its primary purpose is to organize tickets. There is our answer the tickets.

Wait a minute

Now I bet your saying wait, hold on just a minute but I need users and possibly roles. My question to you is do you? is that really pertinent now? I don’t think it is, I used to be in same boat trying set up all this ground work authentication and authorization systems, but is it really needed? In the future maybe,  with a different stakeholder. But for now can we organize tickets as a single user? sure we can yeah it may be a little hectic who created what ticket and who its assigned to, but that is exactly what this iterative development process is meant to solve. Lets worry about those details when we get to them and allow our features to drive the implementation.

What constitutes a feature

I’m sure there is a lot of debate on this topic, however I prefer to take the approach of thinking each individual task that a user wishes to perform as a feature.  Rather then having a features/ directory containing a users.feature , projects.feature, etc.. I tend to think of those  as a module and not really a feature so i prefer to break up my features by module then by feature features/projects/create_project.feature , features/users/destroy_user.feature. while this approach seems to generate more feature files with some being relatively small, I feel it gives me the proper organization and separation of features.

to be continued… I hope to do a follow up post with some demo code as I build out one of my projects.

# required for autotest and rails
sudo gem install autotest autotest-rails

# use osx 10.5 fsevent library instead of traversing the filesystem for changes (lowers CPU usage)
sudo gem install autotest-fsevent

# gives us pretty red, green messages upon failure and succes
sudo gem install redgreen

# provide growl notifications upon success and failures
sudo gem install autotest-growl

now we just include the gems we just installed in our ~/.autotest file

# require gems
require 'autotest/fsevent'
require 'autotest/growl'
require 'redgreen/autotest'

# tell autotest to ignore directories
Autotest.add_hook :initialize do |autotest|
%w{.git .svn .hg .DS_Store ._* vendor}.each {|exception| autotest.add_exception(exception) }
false
end

<mx :Script>
< ![CDATA[
protected var dp:ArrayCollection = new ArrayCollection();
protected function trackGrid_itemDoubleClickHandler(event:ListEvent):void {
var data:Object = dp.getItemAt(event.currentTarget.selectedIndex);
// TODO: what you want to do with the data here
}
]]>
</mx>

<mx :DataGrid dataProvider="{dp}" doubleClickEnabled="true" itemDoubleClick="myGrid_itemDoubleClickHandler(event)" id="myGrid">

</mx>

Install latest readline

ftp://ftp.cwru.edu/pub/bash/readline-6.0.tar.gz
tar -xvzf readline-6.0.tar.gz
cd readline-6.0
./configure
make
sudo make install

Install Ruby Version Manager

sudo gem install rvm
rvm-install

Install Ruby 1.9.2 with RVM

making sure to set as x86_64 and point to our readline

rvm install 1.9.2 -C --enable-shared,--with-readline-dir=/usr/local,--build=x86_64-apple-darwin10
rvm use 1.9.2

Install MySQL gem

also making sure to build with x86_64

env ARCHFLAGS="-arch x86_64" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config