I’m trying to integrate testing as much as possible into the development of Concerto 2.  We’re building in Ruby on Rails, so testing is built into the framework and language, the trick is just getting the team on board and writing tests (and not breaking them as we develop).  To help facilitate testing, I setup BigTuna to run a continuous integration server, automatically testing each version that gets pushed to our GitHub repository.

Since people could be using Ruby 1.8.7 or 1.9.2, we use RVM on testing environment to run tests in both versions.  If you’re looking to replicate our setup which updates git submodules, refreshes the bundle, migrates the database, and finally runs the tests, this set of steps might work for you.

In our setup, we have a database.yml.sample located in our project directory (in our case /bigtuna/builds/concerto) which gets copied over to each build.

rvm 1.8.7 exec bundle install --path=%project_dir%/bundle --deployment
cp %project_dir%/database.yml.sample %build_dir%/config/database.yml
git submodule init && git submodule update
rvm 1.8.7 exec env RAILS_ENV=test bundle exec rake db:migrate --trace
rvm 1.8.7 exec env RAILS_ENV=test bundle exec rake

and for our 1.9.2 tests..

rvm 1.9.2 exec bundle install --path=%project_dir%/bundle --deployment
cp %project_dir%/database.yml.sample %build_dir%/config/database.yml
git submodule init && git submodule update
rvm 1.9.2 exec env RAILS_ENV=test bundle exec rake db:migrate --trace
rvm 1.9.2 exec env RAILS_ENV=test bundle exec rake

Getting the rvm portion of the setup working has been the hardest bit, getting the right ruby environment and bundle of gems to the apps was tough.  The above config was written for rvm 1.2.8 and Bundler 1.0.12, otherwise I don’t believe there are any server-specific configuration parameters at play here.

Best of luck if you’re going the continuous integration route, hopefully you can keep your build green!