Specflow tips: how you can improve your acceptance tests?

Specflow is a great tool for writing acceptance tests, but there are might be a few things that you missed. I would like to share with you those tips how you can make you tests even more readable and maintainable.

Step transform

The step argument transformation is a method that provide conversion from string or table instance to regular .NET type or your custom type. It allow us to provide custom transformation for the parameters supplied in the steps.

That means we can:

• Use meaningful names (aliases) for: GUID identifiers, integer values etc.
• Transform table to custom class instance/collection in one place.

Example: we have a step that takes maximum level as a parameter which is integer value.

Scenario: Cannot level up when reached maximum level
    Given we have a hero 'x' with level 'maximum'
    When we level up hero 'x'
    Then we get an error 'The hero reached maximum level'

To implement step transformation we need to do next:

Context injection

In theory, your scenarios can be as simple as a single Given, When and Then step each. However, in real life they tend to grow and have multiple steps for each of these keyword and as result you need to share data between them.

SpecFlow supports a very simple dependency framework that is able to instantiate and inject class instances for scenarios.

Example: we have a hero model as an input and we want to have ability to initialize it in multiple steps. It makes them more readable and flexible in terms of implementation of further steps.

Scenario: Create a hero
    When we set name 'unknown hero'
    And we select class 'secret'
    And we create a hero
    Then hero is created

To share the data across multiple steps we need to do next:

Note: each scenario execution will have a new copy of the context objects that will be initialized in the Binding classes where they are injected via a constructor.

Scoping

In short, the scoped binding feature allow us duplicate test definitions and run them on scope of: Feature, Scenario, Tag. If there are cases, where we need to change the scope of the step to be executed in certain condition using existing bindings, then we will end up with ambiguity problem. Scoping will help to resolve it.

Example: we have similar steps for hero and monster creation. Let’s use tags to separate them.

@hero
Scenario: Create a hero
    When we set name 'unknown hero'
    And we create a hero
    Then hero is created
    
@monster
Scenario: Create a monster
    When we set name 'unknown monster'
    And we create a monster
    Then monster is created

To restrict our scenarios to the tag we need to do next:

Scenario Outline

Scenario Outline is another useful keyword from Specflow which is used for supporting data-driven tests and is a quite common practice where we try to test the same function with different input/output result.

Basically, keywords like Background and Scenario Outline help to avoid duplicating the scenarios and keep the feature files crisp and simple.

Example: we have scenarios with different outcome of the battle between hero and monster.

Scenario Outline: Hero attack the monster
    Given we have hero 'x' with level '<Hero Level>'
    And we have monster 'y' with level '<Monster Level>'
    When hero 'x' attack the monster 'y'
    Then the result of battle is '<Result>'
Examples: 
    | Hero Level | Monster Level | Result  |
    | maximum    | maximum       | draw    |
    | maximum    | 1             | victory |
    | 1          | maximum       | defeat  |

Hooks

The hooks can be used to perform additional automation logic on specific events, such as before executing a scenario. Hooks are global but can be restricted to run only for features or scenarios with a particular tag.

You can use hooks to set up/clean up tests data for example complex sample data in JSON format or reset state of the application between scenario execution.