How to increase reusability between SpecFlow/Gherkin steps?

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?

Simple

Going out on a limb here, but how come there are so many variations in the first place? Maybe it's a symptom of trying to cover too much with these kind of tests when actually some of them should be moved to the unit level. On the other hand maybe it's an exercise in finding the right level of detail for your DSL (steps). Have you gone through them - the scenarios - with your stake holders? What do they think? – Vienna

Well, we don't discuss them with the stakeholders. We more or less try to 'reverse engineer' the scenarios from an existing system so that we can use them as automated smoke tests. But the variation is mostly caused by keeping the scenarios small and concise. As an example, we might have a step "Given I'm logged in as an administrator", but also "Given I'm logged in" if we don't care about the actual role. – Simple

It' a very difficult question to answer without more context and experience (on my side). Have you drawn a context map and done some possible bounded context analysis to reduce scope of the tests? From the sound of it, these scenarios seem to be security or role oriented. Would it pay off to have them split up on a role by role basis (personas) or is there too much overlap (if so, why is that)? If the tasks/actions roles can perform are dynamic and overlapping (authorization config) there's not much use in splitting them up. Just thinking out loud here ... – Vienna

Not really, but the entire domain is part of the same bounded context, with the exception of the login stuff. But the important question is what the preferred way is: 1. To reuse existing steps in a scenario and use AND to combine them or 2. Define a new step specific for that scenario that basically does the same as 1, but is more concise. – Simple

@DennisDoomen Could you move those steps into your question? It will be better to read them then. – Hydrazine

Two things you haven't shown in your question are: 1) A feature description - "As a <usertype> I want to <process> so that I can <objective>" - this should be a general enough activity that several use cases can be identified as scenarios from it - that will help us answer the question. And 2) additional scenarios which are causing you re-useability issues with the highlighted steps. – Rusty

"Well, we don't discuss them with the stakeholders." - there's the problem. At the very least, get a rubber duck. – Peridotite

Boy that link seems out of date... Secret Ninja Cucumber Scrolls – Pomatum

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.

Fireguard

Answer 2

Adding onto the answer from @gaspar-nagy It follows the pattern of class design in C programming. Anywhere a common group of classes share common properties/methods, those properties/methods can be refactored into a base class.

What it looks like in our SpecFlow tests is that common browser operations are in the base classes:

Login()
Logout()
NavigateToUrl(string url)
UserHasPermission(string permission)
WaitForElementToAppearById(string id)
WaitForElementToAppearByClass(string class)

And each of those methods could have 1 or more Given/When/Then attributes like @gasper-nagy stated.

Another technique which proves invaluable is to share variables between .features and their respective C# step files is to use the ScenarioContext.

For example, whenever Login() is called to initiate our browser based tests, we do this:
ScenarioContext.Current.Set<IWebDriver>(driver, "driver")

Then anywhere else that needs the driver, can get it by:
var driver = ScenarioContext.Current.Get<IWebDriver>("driver")

This makes steps re-usable, such as user input tests for validation you may decide to pass the element being validated around like this: ScenarioContext.Current.Set<IWebElement>(element, "validation-element")

Pomatum