Question

I think I thoroughly understand the concepts and ideas behind SpecFlow, but even after reading the Secret Ninja Cucumber Scrolls, The Cucumber Book, and going through the various forums I’m still unsure about the path to reusability.

Our scenarios already comply to various guidelines

• Self explanatory
• Must have a understandable purpose (what makes it different from the other scenarios)
• Are unique
• Represent vertical functional slices
• Uses Ubiquitous Language
• Written from the stakeholder perspective
• About business functionality, not about software design
• Grouped by Epics
• ARE NOT TEST SCRIPTS
• Let somebody else read them to see if the scenario is correct
• Doesn’t refer to UI elements
• Represent key examples
• Non-technical
• Precise and testable
• As repeatable as possible
• ‘Given’ represent state, not actions
• ‘When’ represent actions
• ‘Then’ should represent a visible change, not some internal event

Our steps have to comply to the following guidelines (some are specific to SpecFlow):

• Uses Ubiquitous Language
• Doesn’t refer to UI elements
• Should not be combined
• Should be reusable and global over all features
• Should not be linked to a specific feature
• Grouped by entities, entity groups or domain concepts
• Don’t create steps to reuse logic in a step definitions file
• Think thoroughly in what Steps file a step belongs
• Don’t reuse steps between phases
• Literal strings in steps must be avoided, but if required use single quotes
• Never apply multiple [Given], [When] or [Then] attributes to the step
  method
• Order the steps according to the phase they represent
• If it is not important for the scenario, it is very important not to mention it

But we still end up with lots of variations of the same steps, even if we use regex placeholders. Especially the rule that if something is not important, you shouldn’t mention it results in those variations. And yes, internally these steps do a lot of reusing, but not in the scenario.

Consider for example the following scenario:

Feature: Signing where both persons are physically available

@Smoke
Scenario: Show remaining time to sign based on previous signature
  Given a draft proposal
  And the first signature has been set
  When I try to set the second signature
  Then the remaining time to sign should be shown

@Smoke
Scenario: Re-signing of the first proposal
  Given a signature that has not been set within the configured time
  And the first signature has just been re-signed
  When I try to set the second signature
  Then the remaining time should start over

Would it be better to combine the two ‘given’ steps into one and loose some reusability?

Some other examples:

Feature: Conditionally show signatures to be signed

@Smoke
Scenario: Show the correct signature for a proposal with a night shift
  Given I have a proposal for the day shift
  When I change it to the night shift
  Then I should only be able to sign for the night shift

@Smoke
Scenario: Show additional signature when extending the shift
  Given I have a suspended proposal for the night shift
  When I extend the period to the day shift
  Then I should confirm extening the period over the shift

Am I missing a fundamental concept here?

Answer 1

This is not an answer, but some hints:

• you can put multiple Given/When/Then attributes on the same method. If the parameters are the same and the difference is only in phrasing, this can be useful
• in many project we use driver/page object pattern, so the step definitions are usually quite short (2-3 lines), so we bother less about the number of them
• I like your scenarios, I would not change them. On the other hand try to focus on the readability and not the reusability. If your language is consistent, the reusability will come.
• For increasing the reusability especially when there are a lot of “variations” of the entity you are talking about, you can consider using the step argument transformations. Here is an example:

you need a class to represent a permit in the tests with decorations:

class PermitDescription{
  bool suspended;
  bool draft;
}

create converter methods:

[StepArgumentTransformation("permit")]
public PermitDescription CreateSimple(){
  return new PermitDescription();
}
[StepArgumentTransformation("draft permit")]
public PermitDescription CreateDraft(){
  return new PermitDescription() { draft = true; }
}
[StepArgumentTransformation("suspended permit")]
public PermitDescription CreateSuspended(){
  return new PermitDescription() { suspended = true; }
}

you can have now more flexible step definitions that require permits:

[Given(@"I have a (.*) for the day shift")]
public void Something(PermitDescription p)
{ ... }

that matches to:

Given I have a permit for the day shift
Given I have a draft permit for the day shift
Given I have a suspended permit for the day shift

of course this is tool that can be also abused, but in some cases it can help.