Ruby: Ways to prevent cucumber reduncancies?

Does anybody have any idea how I would make this shorter and less redundant:

Feature: nosql
  Scenario: flatfile

    Sometimes a user just wants to have flatfile storage like the
    classic Jekyll CMS.  When this is the case we should make sure
    that we adhere to classic folder and file structure, and store
    the generated content in _site unless the user decides that
    they want generation to be stored inside of memcached, then we
    should go ahead and use that.

    Given I have chosen flatfile storage for my site
    When I request a page, "the_page"
    And I have chosen flatfile generation
    Then I should pull the page from "_site"

    Given I have chosen flatfile storage for my site
    When I request a page, "the_page"
    And I have chosen memcached generation
    Then I should pull the page from memcached

I just see too much repeated text and even though Cucumber is meant to help people communicate it just seems like it's made things perhaps "too dumb" because of all the repetition in certain types of scenarios? Unless I am missing something.

There is also the other small problem, how would I make one feature have a dependency of another feature? For example memcached itself is a feature so how would I require that feature in this feature so that if memcached is not implemented yet then flatfile scenario fails when it meets memcached storage.

Edit: Also I know that flatfile storage isn't nosql, I just threw it in there because I haven't decided which nosql besides Git I want... so it was easier to just throw up flatfile for now so I开发者_JAVA百科 can start to grasp cucumber for my projects.

You can use a Background, like this:

Feature: nosql
  Background:
    Sometimes a user just wants to have flatfile storage like the
    classic Jekyll CMS.  When this is the case we should make sure
    that we adhere to classic folder and file structure, and store
    the generated content in _site unless the user decides that
    they want generation to be stored inside of memcached, then we
    should go ahead and use that.

    Given I have chosen flatfile storage for my site
    When I request a page, "the_page"

  Scenario: flatfile
    When I have chosen flatfile generation
    Then I should pull the page from "_site"

  Scenario: memcached
    When I have chosen memcached generation
    Then I should pull the page from memcached

Background is the option, see this.

From looking over your feature, I would say 50% of it falls lower in the testing stack than cucumber. I would write tests from the end users perspective, in that if they choose an option, given a page, they will see that page come back to them as they expect. Once your feature fails for the option, drop down into your lower-level testing framework and write the tests around the type of storage engine you're using.

With Cucumber I always strive for the request/response feedback loop that a user would expect of the system, whether that user is a person, another server, a mobile device, etc. Think more black-box style testing.

An alternative to Background would be to use a Scenario Outline, although these are easy to over-use and hurt readability - use your best judgement:

Scenario Outline: Choosing generation strategy
    Given I have chosen flatfile storage for my site
    When I request a page, "the_page"
    And I have chosen <generation_type> generation
    Then I should pull the page from <storage_type>
Examples:
| generation_type | storage_type |
| flatfile        | "_site"      |
| memcached       | memcached    |

The other part of your question is a little unclear. Cucumber/Gherkin have no notion of dependency between features, and with good reason. I'd argue that memcached is not a feature, rather it's an implementation detail of the 'displaying pages to the user' feature.

If you haven't implemented memcached caching yet, then the scenario will fail, so you should add a @wip tag to it, and tell Cucumber to exclude that tag in CI builds.

Making the flatfile scenario fail if it meets memcached storage is down to how you implement those step definitions. The 'I have chosen flatfile generation' step should set the site up to use flatfile (rather than memcached) generation, and the last step should fail if the page was pulled from the wrong source.