Introduction to xGherkin.net

xGherkin.net is a xspec flavored BDD framework, which tries to strike balance between xspec and xbehave nature. The basic goal of this project is to remain close to plain gherkin as much as feasible given the language constrain (given that we are using c# to write gherkin).

Like any xbehave frameworks it support defining features using pretty much standard Gherkin language syntax. But unlike most of xbehave frameworks e.g. cucumber, specflow; it doesn't support a separate '.feature' file to write down just the features. Instead feature is written in c#. xGherkin.net tries to maintain balance between the feature and step definition (cucumber concepts).

Unlike most xspec framework, xGherkin.net tries to remain as faithful to gherkin as possible.

Getting started with xGherkin.net

xGherkin.net is available as a nuget package. Try using following command.

Install-Package xGherkin.net

Basic Gherkin

Feature Definition

A feature in xGherkin.net must be implemented as a class decorated with 'Feature' attribute. The 'Feature' attribute allows a title and description similar to plain gherkin.

e.g.

Following feature definition in plain gherkin...

 Feature: Some terse yet descriptive text of what is desired
   Textual description of the business value of this feature
   Business rules that govern the scope of the feature
   Any additional information that will make the feature easier to understand

can be written as follows in xGherkin.net:

[Feature("Some terse yet descriptive text of what is desired",
@"Textual description of the business value of this feature
    Business rules that govern the scope of the feature
    Any additional information that will make the feature easier to understand")]
public class MyFeature
{

}

Scenario Definition

A scenario can be described as a method of feature class. Scenario must be decorated with 'Scenario' attribute.

Gherkin:

 Feature: Some terse yet descriptive text of what is desired
   Textual description of the business value of this feature
   Business rules that govern the scope of the feature
   Any additional information that will make the feature easier to understand
 
   Scenario: Some determinable business situation

vs xGherkin.net:

[Feature("Some terse yet descriptive text of what is desired",
@"Textual description of the business value of this feature
    Business rules that govern the scope of the feature
    Any additional information that will make the feature easier to understand")]
public class MyFeature
{
  [Scenario("Some determinable business situation")]
  public void MyScenario()
  {
     
  }
}

Gherkin Steps

One of most notable feature of gherkin is the Given-When-Then step flow. This can be defined in xGherkin.net as series of strings and supporting function definition, looks pretty similar to how step definition is done in ruby while using cucumber framework.

Gherkin:

 Feature: Some terse yet descriptive text of what is desired
   Textual description of the business value of this feature
   Business rules that govern the scope of the feature
   Any additional information that will make the feature easier to understand
 
   Scenario: Some determinable business situation
     Given some precondition
       And some other precondition
      When some action by the actor
       And some other action
       And yet another action
      Then some testable outcome is achieved
       And something else we can check happens too
       But this shouldn't happen

vs xGherkin.net:

[Feature("Some terse yet descriptive text of what is desired",
@"Textual description of the business value of this feature
    Business rules that govern the scope of the feature
    Any additional information that will make the feature easier to understand")]
public class MyFeature
{
  [Scenario("Some determinable business situation")]
  public void MyScenario()
  {
    "Given some precondition".Do(_ => 
    {
    });

    "And some other precondition".Do(_ => 
    {
    });

    "When some action by the actor".Do(_ => 
    {
    });

    "And some other action".Do(_ => 
    {
    });

    "And yet another action".Do(_ => 
    {
    });

    "Then some testable outcome is achieved".Do(_ => 
    {
    });

    "And something else we can check happens too".Do(_ => 
    {
    });

    "But this shouldn't happen".Do(_ => 
    {
    });
  }
}

Note that class name as well as scenario method name doesn't really matter. What really matters is the text descriptions inside the 'Feature' and 'Scenario' attributes.

Some people do prefer to write features as a user story following 'As a ... I want ... so that' syntax. While this is quite popular, xGherkin.net doesn't enforce it. Remember that a feature may be composed of multiple user stories or a user story may be touching multiple features.

That's it folks!