Ruby BlankSlate Issue.. or The Problem Of Accidental Monkey Patching

I was updating a Rails app recently and found the tests weren't running.
The error was reported in HoboField (an ace gem that lets define your model fields within your model and auto-generate your migrations by 'diff'ing between schema and models).

The error was .../hobo_fields/field_declaration_dsl.rb:22 'field': wrong number of arguments (1 for 2)

This was being thrown when ruby was getting to a model class like this...


class SomeModel < ActiveRecord::Base
fields do
timestamps
end
...
end



The error turns out to be because the DSL class in Hobofields uses BlankSlate as it's base class. ActiveSupport also has a definition for BlankSlate, so Hobofields does an 'unless defined? BlankSlate' check before it defines one.

However... I was also using 'Riot' for my testing. Riot also defines BlankSlate.
The ActiveSupport version leaves the instance_eval method on the BlankSlate class. The Riot version removes it and doesn't check to see that BlankSlate is not already defined. Riot was accidentally Monkey Patching ActiveSupport.

As both libraries were being loaded, so the Riot definition was extending the ActiveSupport version and it was loosing it's instance_eval method. This leads to missing method picking up calls it shouldn't and eventually ends in the error I was getting.

I patched Riot and the problem went away. I expect to run into this sort of problem again in the future.

Do me a favor :) If you are developing a gem, please be really careful what you define in global space. It is best to namespace any classes you define so you don't risk cross over.

Thanks

accepts_nested_attributes_for and sti

I have a site that lets you create child entities on the create form for the aggregate root. Thanks to accepts_nested_attributes_for this isn't too hard.

accepts_nested_attributes_for :kids, :allow_destroy => true

The problem I hit was mixing this with single table inheritance. When the child node is for a derived class, it saves without the 'type' information being set.

It seems the accepts_nested_attributes only creates new instances of the generic base class entity, which then ignores the value passed to the 'type' field.

I ended up doing this work around to get it to replace #new on the base class with an implementation that returns the correctly typed derived instance when the hash passed includes a 'type' field.

Thanks to Coderrr for posting this work around.

Note: I've backed up the code to http://gist.github.com/273858

Pit:: Manages your user config settings easily.

Pit is a real 'gem' of a gem.

I have a script that installs a bunch of gems to set up a development environment on rails. The problem is each user of the script needs to set up the proxy for their own specific user settings. I don't want to store that information in the script as everyone would be logged in as me. I don't want to have to remember to manually set up some config file for each user of the system either.

Pit acts like a repository for configuration data. In your code, just ask Pit for specific data and it will either return the known information OR prompt the user with an editor so they can fill in the missing information (which is then remembered). So simple!..

Install: gem install pit

Usage:

   require "pit"
   config = Pit.get("proxy.settings", :require => {
           "username" => "default value",
           "password" => "default value"
   })

Install the gem and run gem server for more information.

The files are hosted at http://rubyforge.org/frs/?group_id=4607

Thanks LowReal whoever you are!

StoryQ

I've been looking at BDD with .Net recently. I'm evaluating a few story runners... There seem to be a few...

• NBehave
  
• NSpecify
  
• StoryQ
  
• NSpec
  
• Spec#
  
• MSpec
  

It's still early days, so I haven't decided on a library yet.

One possibility is the StoryQ story definition library. It isn't a runner, but uses your existing test runner as you define your specs within a test.


[Test]
public void ExecutorRunsTests()
{
var story = new Story("Running a test script");

story.AsA("tester")
.IWant("to run a test script")
.SoThat("I can verify the release meets the acceptance criteria")

.WithScenario("A passing test script")
.Given(() => ThereIsATestFileWithASinglePassingTest())
.When(() => TheTestIsRun())
.Then(() => TheTestPassShouldBeReported())
.And("report no failures or errors")

.WithScenario("A failing test script")
.Given(() => ThereIsATestFileWithASingleFailingTest())
.When(() => TheTestIsRun())
.Then(() => TheTestFailureShouldBeReported())
.And("report the failure")

.WithScenario("An erroring test script")
.Given(() => ThereIsATestFileWithASingleErroringTest())
.When(() => TheTestIsRun())
.Then(() => TheTestErrorShouldBeReported())
.And("report the error")
;
story.Assert();
}


The Statements can be written as Given(() => ThereIsATestFileWithASingleErroringTest()) or .Given("There is a test file with a single erroring test")

This allows you to start by defining them as strings and later go back and introduce the code. This makes the development feel bite sized and focused.

To help with this I wrote a simple VBA Macro to convert from text to a lambda method. It also converts back, but it's not perfect as ToUpper is a lossy operation, but it's good enough.

You can grab the macros here.

Rack Up Some RSpec Tests

Here's a simple rack application to render the output from running RSpec.
(Note: this is tailored to work on windows..)

#\ -w -p 8765
use Rack::Reloader, 0
use Rack::ContentLength

app = proc do |env|
    formatting = '--require "C:\\...\\Ruby RSpec.tmbundle\\Support\\lib\\text_mate_formatter" -f ' + 
'Spec::Runner::Formatter::TextMateFormatter' if env["REQUEST_PATH"] == "/textmate"
    formatting = '-f h' if env["REQUEST_PATH"] == "/html"
    
    out = `spec.bat spec #{formatting}  2>&1`
    format = out=~/\    [ 200, {'Content-Type' => format}, out ]
end

run app

How to use it

Install rack if you haven't already. gem install rack

• To start it, save this code into a file called 'spec_rack.ru'.
  
• Change the '...' to the path to your textmate bundles... (or just ignore it if you don't use E or textmate)
  
• Run rackup spec_rack.ru
  
• visit http://localhost:8765 http://localhost:8765/html or http://localhost:8765/textmate
  

Why Bother?

I'm using RSpec for testing, but the integration with E (the windows clone of Textmate) seems to hang sometimes when there is an error in my code.
Having explorer open with the results so I can just press refresh is working well for me.

I wanted to post a simple rack application as there don't seem to be many examples around.

Cucumber Syntax

Cucumber is the latest incarnation of the RSpec Story runner concept; A complete rewrite by Aslak Hellesoy.

I have been using Cucumber at work as a requirements parser to generate test scripts. Here is a quick guide to the content of the feature files.

Cucumber provides a simple way to parse feature/scenarios that have been written in a english (or whatever your native language is). For Cucumber to understand your features though you need to structure them in a certain way... here is how you do it.

A standard install has the following directory structure...

ProjectDirectory
+ bin
+ features
  - XXX.feature
  - ...
  + step_definitions
    - XXX_steps.rb
    - ...
  + support
    - env.rb
+ lib
+ spec

Features

The features are documented in the files named [feature_name].feature in the features directory.

They follow this pattern:

Feature: [the features name]

In order to [goal]
As a [role]
I want to [action]

[...background...]

[...scenarioes...]

Scenarioes

Cucumber doesn't actually do anything with this information (except the scenarioes and background). It is intended to give a human reader context (and reveal the motivation for) for the scenarioes that follow.

Scenarioes are descriptions of the ways that that feature manifests itself within the application. You would have one scenario for each path through the feature. These are a lot like use cases, but you keep them high level, short and only exercising one path.

Scenarioes is made up of a several steps, and can take the following form:

Scenario: [name of the scenario]
Given [some statement]
When [some action]
Then [expected result of the action on the system]
And [another expectation]

Note: And can be used after Given, When or Then steps.

When you run cucumber against a file it will suggest code to put in your ..._steps.rb files to match any currently undefined steps.

Note: Steps can be parameterized to aid reuse. If you put "quotes" around some part of your step (e.g. Given I am on the "login" screen ), then when cucumber suggests the code for you, it will automatically suggest one that will pass what is between the quotes as an argument.

Given the following customer exist:
|name   | age | email                 |
|rod    | 32  | rod@somewhere.cool    |
|jane   | 35  | jane@somewhere.cool   |
|freddy | 34  | freddy@somewhere.cool |

You can also have steps (Given, When, Then, or And) it this form. This will result in a table of information being passed to your step definition.

Background

Background defines the context that the scenarioes should be run in. In other words a set of Steps that will be executed before each scenario in this file is run.

Background takes the following form:

Background: 
Given ...
And ...
And ...

Scenario Outlines

Scenario Outline: [name of the scenario]
Given [some statement]
When [some action]
Then [expected result of the action on the system]

Examples: [name of example set]
| column A | column B | column C |
| row 1 A  | row 1 B  | row 1 C  |
| row 2 A  | row 2 B  | row 1 C  |

The scenario outline in infact defining several scenarioes. The Outline will be executed by Cucumber once for each row in the Examples table (excluding the first with is the column headings). Any steps within the scenario that include something of the form <column name> will have the <...> substituted with the contents of that column for the current row.

Note: You can include multiple Example tables if you like.

Cucumber uses the features/support/env.rb file to set up cucumber. This is a good place for your:

Before do  |scenario|
...
end

After do
...
end

...blocks to live. These are executed before and after (respectively) each scenario is run.