Gherkin Cheat Sheet

Gherkin is a Business Readable Domain Specific Language. It allows the documentation of what a system should do in natural language (multiple languages are supported) and allows test automation code to be written for the system’s features.

This cheat sheet outlines the language basics.

More...

Advanced SpecFlow: Restricting Step Definition and Hook Execution with Scoped Bindings

SpecFlow is a tool that allows the writing of business-readable tests that can then be automated in code. If you’re new to SpecFlow check out my Pluralsight course or the resources page to get up to speed before looking at these more advanced topics.

Step definitions and hooks by default have global scope within the test project.

For example, take the following feature:

Feature: SomeFeature

Scenario: Scenario 1
    Given A
    When B
    Then C

Scenario: Scenario 2
    Given A
    When X
    Then Z

Here the “Given A” step shares a step definition, note in the following code there is only one step that matches “Given A”:

[Binding]
public class SomeFeatureSteps
{
    [Given]
    public void Given_A()
    {
        // etc.
    }       

    [When]
    public void When_B()
    {
        // etc.
    }
    
    [When]
    public void When_X()
    {
        // etc.
    }
    
    [Then]
    public void Then_C()
    {
        // etc.
    }
    
    [Then]
    public void Then_Z()
    {
        // etc.
    }
}

If for some reason we want different automation code to run for each of the “Given A” steps, we could simply reword one of the steps, then we would have two different step definitions.

More...

Advanced SpecFlow: Using Hooks to Run Additional Automation Code

SpecFlow is a tool that allows the writing of business-readable tests that can then be automated in code. If you’re new to SpecFlow check out my Pluralsight course to get up to speed before looking at these more advanced topics.

In addition to executing test automation code in step definitions, SpecFlow provides a number of additional “hooks” to allow additional code execution at various points during the test execution lifecycle.

For this example, consider the following feature:

Feature: SomeFeature

Scenario: Add New Contact Name
    Given I have entered Sarah
    When I choose add
    Then the contact list should show the new contact

With the following step definitions:

using TechTalk.SpecFlow;

namespace SpecFlowHooks
{
    [Binding]
    public class SomeFeatureSteps
    {
        [Given]
        public void Given_I_have_entered_NEWNAME(string newName)
        {
            // etc.
        }
        
        [When]
        public void When_I_choose_add()
        {
            // etc.   
        }
        
        [Then]
        public void Then_the_contact_list_should_show_the_new_contact()
        {
            // etc.
        }
    }
}

When the scenario is executed we get the following test output:

More...

Advanced SpecFlow: Sharing Data Between Steps with Context Injection

SpecFlow is a tool that allows the writing of business-readable tests that can then be automated in code. If you’re new to SpecFlow check out my Pluralsight course to get up to speed before looking at these more advanced topics.

Individual step definitions that represent the natural language scenarios are separate methods that get executed. Often we need to pass data between these steps. The simplest approaches to get started with are to use simple fields in the class containing the steps or to use the Scenario Context. An alternative to these approaches is to use Context Injection.

For example, imagine the following scenario:

Feature: SomeFeature

Scenario: Add New Contact Name
    Given I have entered Sarah
    When I choose add
    Then the contact list should show the new contact

More...




Automated Acceptance Testing with SpecFlow and Gherkin Course

With my new Pluralsight course you’ll learn how to narrow the gap between the business/customer and the development team by creating business-readable, automated tests.

The course covers how to install SpecFlow in Visual Studio, the Gherkin business-readable domain specific language (DSL), and how to create code-automation from this natural language.

You can find the course on my Pluralsight author page.

Creating Inline Data Driven Tests in xUnit

xUnit.net allows the creation of data-driven tests. These kind of tests get their test data from outside the test method code via parameters added to the test method signature.

Say we had to test a Calculator class and check it’s add method returned the correct results for six different test cases. Without data-driven tests we’d either have to write six separates tests (with almost identical code) or some loop inside our test method containing an assert.

Regular xUnit.net test methods are identified by applying the [Fact] attribute. Data-driven tests instead use the [Theory] attribute.

To get data-driven features and the [Theory] attribute, install the xUnit.net Extensions NuGet package in addition to the standard xUnit.net package.

Creating Inline Data-Driven Tests

The [InlineData] attribute allows us to specify test data that gets passed to the parameters of test method.

So for our Calculator add test we’d start by defining the test method:

More...

New Pluralsight Course: The xUnit.net Testing Framework

My latest Pluralsight course on the xUnit.net testing framework has just been released.

Course Description

Learn the latest in unit testing technology for C#, VB.NET (and other .NET languages) created by the original inventor of NUnit.

xUnit.net is a free, extensible, open source framework designed for programmers that aligns more closely with the .NET platform.

 

You can check it out now on Pluralsight.com.

The Ethereal Second Deliverable of Software Projects

So the project or release or iteration is done. We’ve “finished”. The customer and users are (hopefully) reasonably satisfied, and we say that we’ve delivered the software.

There’s a second hidden deliverable that we don’t usually think about and that’s the malleability of the thing we’ve just delivered. How easy it will be to modify the software in the future.

We can think of it as the “potential cost of future change”.

Even though we cannot measure productivity and estimating this future cost is likely to be either impossible, pointless, or both; it still may be a useful concept.

Once we start to treat the potential cost of future change as a deliverable in its own right, we can have important conversations with the team/customer/user. We can trade off the potential cost for future change against getting the next thing released as soon as possible.

More...