Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Standup 7/15/2009: webrat + selenium-client + cucumber works out of the box; possible RSpec bug


“How to modify a URL with rack middleware before it hits rails routing?”


  • The latest versions of webrat, selenium-client and cucumber gems all work together out of the box now. The only caveat is the latest webrat (0.4.5) hasn’t been packaged as a gem yet. Until the official one is available you can use pivotal-webrat. It’s a gem of the latest webrat.
  • Test pollution between RSpec examples was observed when two sequential examples in the same describe block depended on rails flash messages. Moving each of these examples into their own respective describe block eliminated the cross test pollution. This seems to be a bug in RSpec.

  1. Tim Connor says:

    Won’t pretty much any middleware run by default before the dispatching (and hence routing) in Rails? So just modify @env[“PATH_INFO”] and call @app with the new env, I’d think. What’s the problem, exactly?

  2. Jacob Maine says:

    Sven Fuchs’s [routing_filter]( wraps around the whole routing system and allows to pre- and post-filter both what goes into it (URL recognition) and what comes out of it (URL generation).

  3. Chad Woolley says:

    “the latest webrat (0.4.5) hasn’t been packaged as a gem yet” – couldn’t this have been addressed by just asking Bryan to bump the tiny version in his gemspec (or submitting a pull request doing it for him)? That should have caused github to build his gem, and then you wouldn’t have needed to fork and create a Pivotal-custom package.

    Alternately (and only if Bryan wasn’t responsive enough), you could have done the same thing on Pivotal’s fork. I don’t see a need to push it to our gem server, and indeed I’d prefer it to not live there in permanent obsolescence.

    The only real reason to Pivotal’s gem server should be if we can’t use rubyforge or github’s for some reason. The only reason I know of for that is for redundancy, or if a parent gem wants an exactly-named (that is, no github user prefix) gem. I don’t think the former is true, and the latter can’t be true since you uploaded the prefixed version.

    In other words, I’m against the unnecessary proliferation of gems across multiple sources :)

    — Chad

  4. Jeff Dean says:

    I wrote up a post on rack middleware at – which should provide a bit more info as well.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *