Suppose you’re using the following command to interact with an iframe within capybara:


Sometimes it works, but often you get en error like:

Element is not currently visible and so may not be interacted with

You may be falling prey the retry methods built in to capybara. See, capybara is waiting for something to appear in the dom and keeps retrying failing code until it does.

But what you did, by changing scope with “#swich_to” is made it so a previous passing command is now failing. Technically, you’ve made only what is in the iframe visible to capybara, so when the retry happens, things that were previously there are now not visible; they are still in the DOM, but not in current scope, hence “not visible”.

Try this. In a “background” or “before(:each)” before the test in question:

background { @window_handle = page.driver.browser.window_handle }

..and then, before your assertions:


That will ensure proper DOM scope on the retries.

You may have a point when you’re writing specs that are meant to anticipate a 404 Not Found from a resource. You have a rescue like this:


rescue ActiveResource::ResourceNotFound
return nil

..and now you need a test for it. In Rspec it’s not obvious, but easy. First, you need to stub your actions in your spec:


That sounds good, but it won’t work because it will fail with:

ArgumentError: wrong number of arguments (0 for 1)

Arguments? I need to pass arguments to an error? I guess I do. Maybe the status code?

But no:

NoMethodError: undefined method `code’ for 404:Fixnum

Ah ha! It needs some kind of object passed in to new()! But, what is it? We have no way of knowing off hand what object should be there. Wait, though, we’re INSIDE an environment that exists for making throw-away objects!

Something.stub!(:some_method).and_raise('err', :code => '404'))

Try that, you’ll get your exception!

With the help of code from Fazi bear , I have put together a gem that will pull data from the Sudden Motion Sensor chip inside Apple Macbooks and Macbook Pros.

Prior to this, to read the data you needed to interface with the external AMSTracker command line program. This is a smoother way to do it.

Why would you want this? Because now you can use this to control your code by physically moving your laptop around!

Examples here.

Sudden Motion Sensor at

Github Repo.

require File.dirname(__FILE__) + '/../spec_helper'
describe "RickAstly" do
before(:each) do
@rick =

it "should never give you up" do
@rick.give_you_up?.should be_false

it "should never let you down" do
@rick.let_down(mock_model(You)).should == 'never'

it "should never run around and hurt you" do
@rick.run_around.andand.hurt_you.should be_nil

it "should never make you cry" do
@rick.make_cry(:person => 'you').should have(0).things

it "should never say goodbye" do
lambda { @rick.say(GOODBYE) }.should raise_error(RickAstley::InvalidStringError)

it "should never tell a lie and hurt you" do
@rick.tell.should_not respond_to(:lie)