WESTMONT PICKLES

A Little History

Before SpecFlow and Gherkin showed up to the testing party, most of us were writing unit tests in pure code.

This was fine… if you enjoyed deciphering cryptic test methods and assertions that read like ancient spells.

Enter Behavior-Driven Development (BDD)—a methodology that encourages writing tests in plain English (or whatever human language you prefer).

This makes it easier for developers, testers, and business folks to be on the same page.

Gherkin is the structured language used to describe these tests.

SpecFlow is a C# implementation of BDD, using Gherkin to define test cases in a way that mere mortals can understand.

How Gherkin Works (It’s Not a Pickle, I Swear)

Gherkin follows a simple structure:

• Feature: Describes the functionality you’re testing
• Scenario: A specific example of the feature in action
• Given: The preconditions
• When: The action
• Then: The expected outcome

Example: Testing a Login System (The Classic)

1
2
3
4
5
6
7

Feature: User Login

Scenario: Valid Login
    Given the user enters "admin" as the username
    And the user enters "password123" as the password
    When the user clicks the login button
    Then the user should be redirected to the dashboard

See? It’s like writing a user story instead of a test case. Even your manager can understand it (well, maybe). 😆

How SpecFlow Turns Gherkin Into Automation Magic ✨

SpecFlow takes the Gherkin scenario and maps it to actual C# test code.

Here’s how you’d implement the above scenario in SpecFlow:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

[Binding]
public class LoginSteps
{
    private readonly LoginPage _loginPage = new LoginPage();

    [Given("the user enters \"(.*)\" as the username")]
    public void GivenUserEntersUsername(string username)
    {
        _loginPage.EnterUsername(username);
    }

    [Given("the user enters \"(.*)\" as the password")]
    public void GivenUserEntersPassword(string password)
    {
        _loginPage.EnterPassword(password);
    }

    [When("the user clicks the login button")]
    public void WhenUserClicksLogin()
    {
        _loginPage.ClickLogin();
    }

    [Then("the user should be redirected to the dashboard")]
    public void ThenUserSeesDashboard()
    {
        Assert.IsTrue(_loginPage.IsOnDashboard());
    }
}

The magic here is [Binding], which tells SpecFlow that this class contains the step definitions for your tests.

How It’s Different from Normal Unit Testing

Unit tests are great for checking the nitty-gritty details of individual components, but SpecFlow & Gherkin shine when you want to describe user behavior and ensure everything works end-to-end.

Why Should You Care?

1. Less Confusion, More Clarity – Everyone can read and understand tests.
2. Better Collaboration – No need to explain test cases to non-techies.
3. Reusable Steps – You don’t have to rewrite similar tests over and over.
4. Documentation as Code – Your test cases double as living documentation.
5. It’s Just Cool – I mean, wouldn’t you rather write tests like a story instead of debugging fragile unit tests?

Key Ideas

References

• SpecFlow Documentation
• Gherkin Syntax Guide
• BDD Explained