Pivotal Labs

Main menu

Skip to primary content
Skip to secondary content
  • About
  • Case Studies
  • Team
    • Executives
    • Locations
      • San Francisco (HQ)
      • Boston
      • Boulder
      • Denver
      • London
      • Los Angeles
      • New York
  • Community
    • Blogs
    • Tech Talks
    • Events
  • Careers
    • Lifestyle
    • Principles & Practices
    • Benefits
    • FAQ
    • Apply
  • Contact
    • Press Room
    • Press Releases
    • In The News
    • Press Kit
  • All
  • Labs
  • Standup
  • Tracker

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

Justin Richard
Wednesday, July 15, 2009

Help

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

Interesting

  • 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.
  • 0 Shares
  • Share on Facebook
  • Share on Twitter

4 Comments

  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?

    July 15, 2009 at 10:55 am

  2. Jacob Maine says:

    Sven Fuchs’s [routing_filter](http://github.com/svenfuchs/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).

    July 15, 2009 at 11:07 am

  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

    July 15, 2009 at 8:00 pm

  4. Jeff Dean says:

    I wrote up a post on rack middleware at http://pivotallabs.com/users/jdean/blog/articles/889-sanitizing-post-params-with-custom-rack-middleware – which should provide a bit more info as well.

    July 15, 2009 at 10:25 pm

Add New Comment Cancel reply

Your email address will not be published.

Justin Richard

Justin Richard
San Francisco

Recent Posts

  • [Standup][SF] 11/07/12: CSS tech talk at AirBnB tonight
  • 5/18/12 Standup – Performance without downtime please
  • 5/15/12 Standup – setting the template in database.yml
Subscribe to Justin's Feed

Author Topics

agile (6)
  • About
  • Case Studies
  • Team
  • Community
  • Careers
  • Contact
  • Labs
  • Events

Contact Us

contact@pivotallabs.com
+1 415-77-PIVOT
TwitterLinkedInFacebook

Pivotal Tracker

Tracker is the award-winning agile project management tool that enables real-time collaboration around a shared, prioritized backlog.
Visit pivotaltracker.com >