title: Limit cucumber steps or steps file to specified feature or tag
body: <p>I've written a modal slideshow for our web app that presents a navigation for sets of documents and exposes various metadata for those documents.</p>
  
  <p>This is a large component of the application with esoteric requirements, so I think it's fair enough that its core scenarios (given to me as acceptance criteria) should be both numerous yet internally consistent.</p>
  
  <p>To avoid having a new step for each of our many scenarios, I've adapted <a href="http://bjeanes.com/2010/09/selector-free-cucumber-scenarios">a helper</a> which translates human-readable terms such as <code>document caption</code> into selectors:</p>
  
  <pre><code>module SelectorsHelper
    def selector_for(term)
      case term
      # Lightbox / modal / fancybox
      when 'lightbox'
          '#fancybox-inner'
      when 'close button'
          '.document-viewer__tools__close'
  </code></pre>
  
  <p>…alongside a few generic step definitions such as the following:</p>
  
  <pre><code># Generic click action
  When(/^I click (?:on )?(?:the |a )'(.*?)'?$/) do |element|
    find(selector_for(element)).click
  end
  </code></pre>
  
  <p>The problem, whether I'm acting on very generic notions as with the above or more specific abstractions involving patterns that recur within a set of features, is that these may wreak havoc with other esoteric features, which may have much more specific steps to parse them. Every Cucumber example I've seen has step definition files whose filename bears a procedural relationship to a specific feature file, and my assumption was that in these cases, that step definition file would only be called to parse the scenarios in it's related feature:</p>
  
  <pre><code>+ features
  | + step_definitions
  | | + global_steps.rb
  | | + modal_steps.rb
  | | + login_steps.rb
  | + modal.feature
  | + login.feature
  </code></pre>
  
  <p>But that isn't the case — and I'm struggling to resign myself to the notion that Cucumber attempts to apply <em>every</em> step definition patterns to <em>every</em> scenario. If these tests are going to have any merit, they'll grow more numerous, introduce new concepts, and stay relevant without continuous re-writing. I want to be able to limit the scope of my steps to stop them interfering with features they weren't written for, but don't know how. The following conceptual solutions come to mind:</p>
  
  <ul>
  <li>Use background or scenario <code>@tags</code> and invoke steps only for scenarios with those tags</li>
  <li>Nest step definitions in some kind of wrapping helper or meta-step-definition that's invoked by a fallacious background given</li>
  </ul>
  
  <p>I'm unfamiliar with Ruby and Cucumber seems extremely thin, so I'm daunted by unlimited potential on the one hand and no pre-determined implementation on the other. Any ideas?</p>