Design Reusable Steps Specflow-Is this approach correct

Question

We are new to Specflow & trying to implement it in our company, we have developed few features as part of Smoke/Regression Test & are currently executing.We are following approach as described - Specflow,Selenium-Share data between different Step definitions or classes What we observed is for resusing steps - the steps have to be broken down to its most component/unit feature as shown below-

Scenario: Search Cash book by Id
    Given Site browser launched
    Given Login is successful with "******" and "********"
    Given Set the service to "*******"
    Given Search a specific account "ABCDEFG" to match "Account"
    When A specific account is selected "ABCDEFG"
    When I search cash book with these data "CSX"
    Then the result should display records with transaction Amount "$1234"

What we observed is if your steps are not described as above, their reusability is very limited in other features. Is this approach right or need steps with respect to features rather than re-usability?

AutomatedChaos · Accepted Answer · 2015-08-17T14:44:08.127

Specification by example is not the same as keyword driven testing as what you try to achieve above. A true BDD approach would be something like this:

Feature: Viewing transaction amounts in certain cashbooks
As a customer
In order to know if I am paid
I want to see the amount next to a transaction

Background:
Given the following transaction:
    | Name      | Account   | CashBook | Transaction | Amount |
    | CustomerA | ABCDEFG   | CSX      | GlipGlob    | 1234   |

Scenario: A Cash book can be searched by ID
    Given I am logged in as CustomerA
    And I have selected the account "ABCDEFG"
    And I have selected the cash book "CSX"
    Then there should be a transaction with amount "1234"

The background checks the existance and/or sets up the data. How that is done is not important for the feature (implementation detail). This could be done by a direct DB query, a webservice or through the GUI (not recommended).

The scenario runs also without the implementation context: It doesn't matter if you run this as a webserver, through a browser or as a Windows Phone app. Therefore, information as "checking checkboxes" or "filling editboxes" and "clicking links" should not be present in a feature. With the exception if you are testing specific page layout.

At the start of your test design, this makes your steps not very reusable on a low level, so you have to make reusable steps in your glue code. For Selenium en webtesting, you can use the page object pattern to achieve this.

At the end, you'll have a more flexible framework. When the checkbox is changed to a radiobutton or just a link on the object, you only need to change one method in the page object instead of changing 100 feature files.
If management decides they want an iPhone app, you can reuse all your tests with only making a different interface to your glue code.
When the developer hands you a REST API to the application because it is needed to interconnect with other sources, you can just reuse the same feature files with only changing the glue code.

So, yes, on a low level steps are not very reusable if objects are not defined in the steps, but it will give you a huge advantage in the long run. When you want to use low level step inside readible step definitions, maybe SpecFlow is the wrong framework for you.

@AutomatedChaos-I do implement POM & try to make the steps as reusable as possible. Have edited the feature file on top- Thanks for all the inputs.Really Helpful. — ReuseAutomator, Aug 27 '15 at 02:32

Design Reusable Steps Specflow-Is this approach correct

1 Answers1