Simple Thoughts

fairtilizer.com is now known as official.fm

2010-09-03T16:08:48+02:00

I've been working on fairtilizer.com pretty much full time for the last 2 years. This august the team flipped the switch on a new branding Official.fm, the idea being massiveattack.official.fm. As I was off on holidays, huge congratulations to the officialfm team are due. Hopefully will be blogging more often now (I think I said that about 2 years ago too :)

Created mongrel dont-serve-static patch ticket

2008-01-24T12:51:00+01:00

If anyone’s interested, I’ve updated the patch for mongrel trunk (r949 / REL_1-1-3) and posted it here to the mongrel project

I’m hoping this get’s in. Am I too hopefull? :)

Mocking ActiveRecord::RecordInvalid with mocha

2008-01-23T13:12:00+01:00

For future reference


        def mock_record_invalid(model)
          user_errors, record_invalid_error = mock('errors'), mock('record_invalid_error')
          user_errors.stubs(:full_messages).returns([])
          model.stubs(:errors).returns(user_errors)
          record_invalid_error.stubs(:exception).returns(ActiveRecord::RecordInvalid.new(model))
          record_invalid_error
        end

RSpec Story Runner Driven (Browser) Acceptance Testing

2008-01-18T12:30:00+01:00

I’ve been using rspec now for quite a while now (thanks to chrissturm) and have been loving it. It feels a lot more natural and intuitive and I’m even getting the hand of learning when/how to mock/stub (though I still have some fixtures lying around). I’ve been meaning to learn up on using the new story runner feature and while googling I came upon a post by Kerry Buckley in which he provides a quick overview of how to setup story runner and also describes how he got story runner to drive selenium acceptance testing.

Just a quick blurb about what story runner is.

Story runner basically allows you to write specifications in a plain text file, written in natural language. You basically write a story (paraphrasing Dan North “a description of a requirement and its business benefit, and a set of criteria by which we all agree that it is done”.)

For each story you can then write a number of different scenarios (imagine that feature in different situations) and for each scenario you write a set of criteria which determines how that scenario can be completed successfully.

e.g.


       Story: UI
        As a developer                                                  #
        I want to go to the uimockups page                              # Description of intent
        So that I can implement the mockup                              #
      
         Scenario: Going to the /uimockups page when not logged in      <= Scenario Description
           Given an anonymous user                                      #
           When the user goes to /uimockups                             #
           Then the document title should be 'personal'                 # criteria, actions & expectations
           And the page should contain the text 'done by Webtypes'      #  
           And the page should have a field named 'strip-search-input'  #
           And the page should have a form named 'strip-search'         #

Given a text file like this, you then write a small ruby script (see /stories/stories/project.rb below) which then takes the text, parses it look for the highlighted keywords. Each Given, When and Then is a Step. The Ands are each the same kind as the previous Step.

Run as is, you’ll get this same story output back to you but each of the lines under Scenario will be marked with “pending” which basically means that the story is yet to be implemented. e.g.


      saimon@artemis~/dev/projects/myrailsapp$ ruby stories/stories/project.rb
      (in /Users/saimon/dev/projects/myrailsapp)
      Running 1 scenarios
      
      Story: UI
      
        As a developer
        I want to go to the ui page
        So that I can see the mockup
      
        Scenario: Going to the /ui page when not logged in
      
          Given an anonymous user (PENDING)
      
          When the user goes to /ui (PENDING)
      
          Then the document title should be 'personal' (PENDING)
          And the page should contain the text 'done by Webtypes' (PENDING)
          And the page should have a field named 'strip-search-input' (PENDING)
          And the page should have a form named 'strip-search' (PENDING)
      
      1 scenarios: 0 succeeded, 0 failed, 1 pending
      
      Pending Steps:
      1) UI (Going to the /ui page when not logged in): Unimplemented step: an anonymous user

To actually get the story to pass, you need to implement each of the Steps in ruby. i.e. Here’s an example of the implementation of the 2nd step:

“When the user goes to /ui (PENDING)”


      steps_for(:project) do
        When "the user goes to $path" do |path|
          get path
        end
      end

As you can see it’s basically parsing the line for a step keyword (in this case ‘When’), and then takes the rest of the line and tries to match it against any of the When steps it knows about. It also goes one step further and allows you to add in variables so that you can extract dynamic criteria directly from the story line ($path) in this case.

So once, it has been matched, it ends up executing :

12	get /uimockups

The cool thing about it is that once you’ve implemented a step, it’s just reused every time it’s matched in the story. You can also have a stable set of steps which you use in multiple stories. You could even conceivably build up a library of them to be used in other applications.

I was at the BCN Ruby/Rails group meeting last night and one of the attendants expressed concerns about the brittleness of the syntax. In fact, there’s no problem because story runner will mark any line that it hasn’t been able to match against any of the steps known to it as pending so you can easily determine a syntax problem. And if an exception is raised by anything it has matched then it’ll provide the appropriate stack trace pointing you to the step that caused the exception.

After watching Pat Maddox’s screen-cast I’m convinced that using story runner is a good way of starting out your speccing. You can start by writing a story that describes a feature and then drill into it as you implement the steps. Along the way you’ll find you need to implement controllers, models, helpers and views and before you do you can then implement the appropriate specs (only enough to get the functionality in the story passing) which in turn drives the implementation of the object in question.

Now, finally, I can get to the real reason I wrote this post.

I’m interested in being able to do my integration tests via story runner and occasionally do the odd browser acceptance testing and as I also had been meaning to play with FireWatir & SafariWatir I decided to adapt his code to using watir.

But I added another requirement to the mix. What I really wanted was seamless integration between normal integration tests using plain rspec and browser acceptance testing hen running the same scenarios or even be able to mix and match.

After a bit I come up with this setup (very similar to Kerry’s original setup):

Directory Structure:


      +-- lib
      | +-- tasks/
      |   +-- acceptance.rake
      +-- stories/
      | +-- all.rb
      | +-- helper.rb
      | +-- steps/
      | | +-- project.rb
      | | +-- watir.rb
      | +-- stories/
      | | +-- project.rb
      | | +-- project.txt

Note: As per Kerry’s article I’ve further subdivided the top-level stories directory into stories and steps subdirectories. You don’t have to if you don’t have that many stories to write but I like the organized feeling it provides.

/stories/all.rb


      dir = File.dirname(__FILE__)
      require "#{dir}/helper"
      Dir[File.expand_path("#{dir}/stories/**/*.rb")].uniq.each do |file|
        require file
      end

/stories/stories/project.txt


      Story: UI
        As a developer
        I want to go to the ui page
        So that I can see the mockup
      
        Scenario: Going to the /ui page when not logged in
          When the user goes to /ui
          Then the document title should be 'personal'
          And the page should contain the text 'done by Webtypes'
          And the page should have a field named 'strip-search-input'
          And the page should have a form named 'strip-search'

/stories/stories/project.rb


      #Call me with: [BROWSER=firefox|safari|ie] ruby stories/stories/project.rb
      require File.join(File.dirname(__FILE__), "../helper") 
      run_story_with_steps_for (browser ? [:watir_project, :project] : [:project])

/stories/steps/project.rb


      steps_for(:project) do
        Given "a test user" do
          User.delete_all
          User.create!(:name => 'test', :openid_url => 'http://dummy.openid/',
                      :email => 'test@example.com')
        end
        
        When "the user goes to $path" do |path|
          get path
        end
        
        Then "the document title should be '$title'" do |title|
          response.should have_tag('title', title)
        end
      
        Then "the page should contain the text '$text'" do |text|
          response.should have_text(/#{text}/)
        end
        
        Then "the page should have a field named '$field'" do |field|
          response.should have_tag("input[type=text][id=?]", field)
        end
        
        Then "the page should have a form named '$form'" do |form|
          response.should have_tag("form[id=?]", form)
        end  
      
        Then "the page should have a submit button named '$name', with the label '$label'" do |name, label|
          response.should have_tag("input[type=submit][id=?][value=?]", name,label)
        end  
      end

/stories/steps/watir_project.rb


      steps_for(:watir_project) do
        When "the user goes to $path" do |path|
          browser.goto "http://localhost#{path}"
        end
        
        When "the user types '$text' into the $field field" do |text, field|
          browser.text_field(:name,field).set(text)
        end
        
        When "the user clicks the $button button" do |button|
          browser.button(:value, button).click
        end
      
        Then "the document title should be '$title'" do |title|
          browser.title.should == title
        end
      
        Then "the page should contain the text '$text'" do |text|
          browser.text.include?(text).should be_true
        end
        
        Then "the page should have a field named '$field'" do |field|
          (browser.text_field(:name, field).exists? || browser.text_field(:id, field).exists?).should be_true
        end
        
        Then "the page should have a form named '$form'" do |form|
          (browser.form(:name, form).exists? || browser.form(:id, form).exists?).should be_true
        end  
      
        Then "the page should have a submit button named '$name', with the label '$label'" do |name, label|
          tf = (browser.text_field(:name, field) || browser.text_field(:id, field)).exists?().should be_true
          tf.value.should == label
        end
      end

/stories/helper.rb :


      ENV["RAILS_ENV"] = "test"
      require File.expand_path(File.dirname(__FILE__) + "/../config/environment")
      require 'spec/rails/story_adapter'
      
      # watir gem
      require 'firewatir' if ENV['BROWSER'] && ENV['BROWSER'] == 'firefox'
      require 'safariwatir' if ENV['BROWSER'] && ENV['BROWSER'] == 'safari'
      
      def start_ff
        FireWatir::Firefox.new
      end
      
      def start_safari
        safari = Watir::Safari.new
      end
      
      
      #Require steps in steps dir
      Dir[File.dirname(__FILE__) + "/steps/*.rb"].uniq.each { |file| require file }
      
      #Require appropriate watir browser object
      if !$ff && ENV['BROWSER'] == 'firefox'
        $ff = start_ff_with_logger
      end
      
      if !$sf && ENV['BROWSER'] == 'safari'
        $sf = start_safari_with_logger
      end
      
      #Choose which browser to use in steps
      def browser
        $ff || $sf
      end
      
      def run_story_with_steps_for *steps
        with_steps_for *(steps.flatten) do
          # Pull the filename of the caller out of the stack. Must be a better way.
          run caller[3].sub(/\.rb:.*/, '.txt'), :type => RailsStory
        end
      end
      
      # By default, RSpec adds an ActiveRecordSafetyListener to the story runner. 
      # This rolls back database changes between scenarios, which is great if your calling your code directly, 
      # but obviously means that if you write to the database, the server that Selenium's talking to can't see them. There's probably a cleaner way of disabling it.
      class Spec::Story::Runner::ScenarioRunner
        def initialize
          @listeners = []
        end
      end
      
      module ::ActionController #:nodoc:
        module TestProcess
          # Work around Rails ticket http://dev.rubyonrails.org/ticket/1937
          # Helps to remove annoying html parser warnings
          def html_document
            @html_document ||= HTML::Document.new(@response.body, true, true)
          end
        end
      end

So once you’ve got all that setup, you can then run:

123	saimon@artemis~/dev/projects/myrailsapp$ ruby stories/stories/project.rb

to execute the project story using basic rspec. It provides the following output:


      Running 1 scenarios
      
      Story: UI
      
        As a developer
        I want to go to the ui page
        So that I can see the mockup
      
        Scenario: Going to the /ui page when not logged in
      
          Given an anonymous user
      
          When the user goes to /ui
      
          Then the document title should be 'personal'
          And the page should contain the text 'done by Webtypes'
          And the page should have a field named 'strip-search-input'
          And the page should have a form named 'strip-search'
      
      1 scenarios: 1 succeeded, 0 failed, 0 pending

Woot! You can know just take that project.txt and send it to a client, a fellow developer, a project mailing list etc…

But, let’s go the extra step and run that same scenario against Firefox (go to FireWatir and follow the instructions. They’re pretty simple.)

Start firefox with -jssh


      saimon@artemis~/dev/projects/myrailsapp$ 
      /Applications/Firefox.app/Contents/MacOS/firefox -jssh
      
      run the story with the BROWSER environment variable:
      
      saimon@artemis~/dev/projects/myrailsapp$ 
      BROWSER=firefox ruby stories/stories/project.rb

and watch how FF is magically commanded to go through your stories scenarios. In the end it’s run the story against FF and provides the same passing output as the previous run.

One further step is to write a few rake commands to simplify running all your stories, with or without browser acceptance testing.

Add this file:

/lib/tasks/acceptance.rake


      desc "Run the acceptance tests, starting/stopping the test server."
      task :acceptance_with_browser => ['acceptance:server:start'] do
        begin
          Rake::Task['acceptance:run'].invoke
        ensure
          Rake::Task['acceptance:server:stop'].invoke
        end
      end
      %w(firefox safari).each do |browser|
        Object.class_eval <<-EOS
          desc "Run the acceptance tests using the #{browser} browser."
          task :acceptance_with_#{browser} do
            $browser = '#{browser}'
            Rake::Task['acceptance_with_browser'].invoke
          end
        EOS
      end
       
      namespace :acceptance do
        desc "Run the acceptance tests."
        task :run do
          system "#{$browser ? "BROWSER='#{$browser}' " : ''}ruby stories/all.rb"
        end
      
        namespace :server do
          desc "Start the mongrel server"
          task :start do
            system 'script/server -e test -d'
            sleep 5
          end
      
          desc "Stop the mongrel server"
          task :stop do
            if File.exist? MONGREL_SERVER_PID_FILE
              pid = File.read(MONGREL_SERVER_PID_FILE).to_i
              Process.kill 'TERM', pid
              FileUtils.rm MONGREL_SERVER_PID_FILE
            else
              puts "#{MONGREL_SERVER_PID_FILE} not found"
            end
          end
        end
      end
      
      MONGREL_SERVER_PID_FILE = 'tmp/pids/mongrel.pid'

Then you can do:


      saimon@artemis~/dev/projects/myrailsapp$ 
      rake acceptance:run
      
      or 
      
      rake acceptance_with_firefox
      
      or 
      
      rake acceptance_with_safari

I thoroughly enjoyed getting that setup and though I only plan on writing browser specs for specific issues/features it’s nice to have the choice and the geek factor is way up high :)

Have fun speccing…

Git plugin for CruiseControlRB

2007-12-19T13:24:00+01:00

A couple of thursday’s ago I went to the first ever BCN ruby/rails group meeting and though short had some interesting chats. I was also trying to convince people how great git was but I complained that cruisecontrolrb was lacking support for git.

I resolved to fix that. After some googling I couldn’t find anything already out there, so I wrote a plugin myself. You can grab it via

git clone git://saimonmoore.net/cruisecontrolrb.git

You’ll notice the whole cruisecontrol-1.2.1 app is bundled in that repo. If you want to use the plugin for an existing cruisecontrol setup then just grab the plugin from vendor/plugins and apply this patch (this may make itself into the next ccrb release so check)

To add a git-based project:

./cruise add cruisecontrolrb --scm git --url git://saimonmoore.net/cruisecontrolrb.git

then just start the server:

./cruise start

Baby list

2007-12-10T08:03:00+01:00

These are some of the things we (need/think we need/would like to have) for when Sofia makes her grand entrance:

Adjustable Chair – Stokke Tripp Trapp
Baby Walki Talkies
Baby dresser (something like this but foldable)
bouncing cradle (something like this)
play mat (this looks nice)
baby carriers (front / back (for mountain excursions) so not exactly these shown but more or less)
Bugaboo baby nest (in red)
bugaboo baby footmuff (in red)
bugaboo parasol (in red)
Not sure what else for now

If you want to buy one of these, then please choose which one you’d like to buy and let us know so we can remove it from the list so as to avoid others buying the same item.

Saimon and Maria

My MacBook has just been fixed (3 weeks later)

2007-11-16T09:41:00+01:00

fearoffish: This is for you :)

Just a quick note to say that Apple has replaced my faulty HD, quicker than they said they would. I was expecting it in a week but it’s a week early. Suffice to say that doesn’t exone the fact that it took them 3 weeks to do so but I have to give credit where credit’s due. :)

My Macbook's HD just fried itself

2007-11-07T12:22:00+01:00

I bought a Macbook ~4 months ago.

Last week my Macbook refused to startup after a reboot. I took it in to an Apple shop and they said it would take a week to repair. It’s been more than a week and they’ve now told me, that they get the HD’s from the Netherlands and that they’ve run out of stock. Yep, you heard right, they’ve run out of stocks of HD’s belonging to 4 month old macbooks.

I’ll post again when it has actually been replaced.

Gitting git-1.5.3.x installed in Ubuntu

2007-11-07T12:11:00+01:00

I’m looking into git as an alternative to subversion.

As most of my servers use a non-standard port for sshd I was interested in trying out git-1.5.3.x for it’s support for ssh://name@host:port/ but ubuntu gutsy only had 1.5.2.5 available so off to #git I went:

For Ubuntu Gutsy:

apt-get install devscripts fakeroot
dget -x http://ftp.debian.org/debian/pool/main/g/git-core/git-core_1.5.3.5-1.dsc
cd git-core-1.5.3.5
apt-get build-dep git-core
dpkg-buildpackage -rfakeroot -us -uc

~~For Ubuntu Dapper~~:

Update: Apparently the version of dpkg-buildpackage that comes with dapper is too old, so in the end I upgraded Dapper > Edgy > Feisty > Gutsy

~~apt-get install devscripts fakeroot~~
~~wget http://www.backports.org/debian/pool/main/g/git-core/git-core_1.5.3.4-1_{bpo40+1.dsc (as dget doesn’t exist in devscripts on dapper)}~~
~~wget http://www.backports.org/debian/pool/main/g/git-core/git-core_1.5.3.4-1bpo40+1.diff.gz~~
~~wget http://www.backports.org/debian/pool/main/g/git-core/git-core_1.5.3.4.orig.tar.gz~~
~~dpkg-source -x git-core_1.5.3.4-1~bpo40+1.dsc~~
~~cd git-core-1.5.3.4~~
~~apt-get build-dep git-core~~
~~dpkg-buildpackage -rfakeroot -us -uc~~

~~(You may need to manually install libsvn-core-perl && tcl8.4 )~~

Many thanks to MadCoder on #git for helping me out with this.

I’ll be posting about my exploits with git in future posts.

Mephisto_i18n update

2007-11-02T15:23:00+01:00

Just a quick heads up on the status of this for those who are interested.

Though it may seem that this project has died from lack of activity, I am still very much maintaining this project and have been adding fixes and tweaks on and off during the last few months.

In fact, I’ve just committed a couple of fixes:

Correct subdomain parsing for non-multisite mephisto instances (Bug was introduced when adding multisite support)
Making the dynamic i18n link switcher drop method handle paged articles whose section is the home section.

The future status of this project is basically pending a rewrite of globalize. I had already written the next version of globalize (currently stored in a branch) with support for rfc4646 but with the new rails i18n api talks going on, I’m waiting for these to conclude and get the rewrite for globalize 2 done before updating this plugin for that new version.

So….

To all those currently/thinking of using the plugin, feel free to bug me with questions, bug reports and help. I’m still commited to maintaining this.

Btw, the latest version in trunk also has support for plugin template handlers, so you can now use erb, haml or whatever else takes your fancy.