Feature specs

[ivanoblomov]

Now that Cucumber and Gherkin are going out of style, how about developing standards for feature specs?

Apart from a couple years-old tutorials, the web is relatively shy on best practices here. And unlike unit testing (whose structure is largely dictated by method signatures), user functionality can be broken down in many ways. Though Gherkin oversold its promise, the consistent structure it imposed was one of its strengths.

Anyway, it would make sense for any stylebook on integration/acceptance testing to be hosted here.

[pirj]

Nice idea! A PR is welcome. Userful resources: rubocop-capybara’s cops documentation; rspec-rails docs on feature and system specs; Rails guides about integration and system tests.

Ideally, like with the rest of the style guides, the guidelines should reflect real usages, and for this the best source is real-world-rspec, but I imagine it’s quite an effort to harvest it.

Anyway, we can start small, eg by extracting the defaults from rubocop-capybara and turning those into guidelines, and see where it leads us. I suppose we’ll gather plenty of generalised information on how the community writes those specs so we can turn those observations into guidelines.

Does this sound reasonable?

[ivanoblomov]

Sounds good to me! Thanks for all the resource links.

One thing that's always been useful for me is using rspec --format d regularly, especially when first formulating the specs. This way, getting the output right enforces some discipline. For example:

GoogleMapsGeocoder
  #new
    when API key is valid
      with "White House"
        is expected to be partial match
        is expected not to be exact match
        #formatted_street_address
          is expected to eq "1600 Pennsylvania Avenue Northwest"
    when API key is invalid
      is expected to raise GoogleMapsGeocoder::GeocodingError