In this post i will be looking more into Binding Classes and methods. We will also discuss the main backbone of the Scenario steps defined in the feature file i.e. Step Definitions. I will only try and cover what i feel realistically you will need to learn and will most likely use on day to day basis.

Agenda:

  • Binding Class, Methods and Step Definition
  • Step Bindings in a different project
  • Additional Steps Generation

Pre-requisite and Tools:

 

Binding Class, Methods and Step Definition

Here are the bindings and step definitions from the previous post. A typical 'binding Class' will begin with the [Binding] attribute. Without it, Specflow will not be able to detect it as a class with step definitions or 'usable methods'.

Here is our sample scenario again

Scenario: Add two numbers
Given I have entered 50 into the calculator
And I have entered 70 into the calculator
When I press add
Then the result should be 120 on the screen

You will notice that we have 4 steps in the scenario, but only 3 methods in the step definition class. This is because Specflow knows that the first and second steps represent the same action and only the data being passed in, is different. Automatically we have gained re-usability of that particular step.

Be wary of the And keyword, it takes after the immediately preceding keyword. This means that if your previous step is a When statement and you use And after, Specflow will assume that line is a When line.

Example;

  • Given I have entered 50 into the calculator
  • And I have entered 70 into the calculator
  • When I press add
  • Then the result should be 120 on the screen

The above is equivalent to:

  • Given I have entered 50 into the calculator
  • Given I have entered 70 into the calculator
  • When I press add
  • Then the result should be 120 on the screen

But NOT Equivalent to:

  • Given I have entered 50 into the calculator
  • And I have entered 70 into the calculator
  • And I press add
  • Then the result should be 120 on the screen

The "And I press add" step will not be able to locate its binding step, because its binding method is being decorated with the When type attribute.

Also note that the parameters passed in to the attribute in the binding steps is equivalent to the text in our scenario steps. If Specflow detects that data needs to be passed in, it uses regex to indicate this.

If we change :

Given I have entered 50 into the calculator to
Given I Input 50 into the calculator

We will have to change the attribute parameter in the binding methods as follows:

[Given(@"I have entered (.*) into the calculator")] to

[Given(@"I Input (.*) into the calculator")]

Sometimes Our setup steps could act as the action step in other scenarios i.e. a 'When' step for one scenario will read better named as a 'Given' step for another scenario, Specflow allows for multiple Attribute on the method.

for Example :

Given I have entered 50 into the calculator to
could read better as
When I have entered 50 into the calculator

instead of creating two separate methods in the binding class, we could just have;

        [When(@"I have entered (.*) into the calculator")]

        [Given(@"I have entered (.*) into the calculator")]         public void GivenIHaveEnteredIntoTheCalculator(int p0)

The actual method name can be anything. I usually leave it as default or to match the step name.

Parameters

Finally,  you will also notice Specflow was able to detect which method requires a parameter, hence, the value can be passed in from the feature file level. This value will be whatever '(.*)' is, in the text. It will also try its best to detect the data type.

GivenIHaveEnteredIntoTheCalculator(int p0)

It is also good practice to rename your parameters to something more informative.

Manual Steps Generation

For any reason if you will want to generate the step definition class manually, here is a summary of the rules to follow;

  • It must be in a public class, marked with the [Binding] attribute.
  • The binding Method must be a public method.
  • Can be either a static or an instance method.
  • If it is an instance method, the containing class will be instantiated once for every scenario.
  • Cannot have out or ref parameters.
  • Cannot have a return type.

Step Bindings in a different Project

At the moment we have everything in a single project, however, you may prefer to have the step definitions in a separate project. Could be because you later need to reuse the bindings steps across multiple projects etc.

Lets separate the bindings into a different project.

Create another unit test project within the solution called TatAuto.Bindings

  • Right Click on solution -> Add -> New Project
  • Move the Steps folder into the new '.Bindings Project' (you can just cut and paste)
  • Delete the UnitTest.cs file auto generated

  • Include reference to Specflow in the new project, so Add Specflow.Mstest via NuGet like before.
  • The next thing is to Add reference to the Bindings project

Finally we need to inform Specflow of the name of the external Binding assembly to include in search for step definitions.

  • We add the following into our App.Config file in the '.Test project'.
  • Now Do a Build , context click on one of your steps in the feature file and select 'Go To Step Definition'
  • You should be able to navigate directly to the binding step.
  • Re-run your tests again and it should pass just like before.

Additional Steps Generation

If you want to include additional steps within the same Step definition class, it may be useful to
Right click the step and select Generate Step definition as we did before, however instead of saving the class, just copy the methods to clipboard, and then manually paste it into the previously generated class.

 

Conclusion

In this post we have seen Specflow in action. We have tested the addition of two numbers.
So far you will noticed, I did not say much about Test Automation, even after the third tutorial on Specflow. This is a deliberate attempt to help us focus on what Specflow really is. i.e. a primarily BDD tool which can optionally be used in Test Automation.

References

Specflow Documentation

Any thoughts, questions, comments, addition, or anything you don’t like, do not hesitate to leave a comment or contact me. Thank you!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Show Buttons
Hide Buttons