This site works best in modern browsers. Looks like you're using an old one, you should upgrade if you can.

An Update on FeatureToggle v3 Development

The next version of my open source feature toggling library is currently in development.

Version 3 will introduce a number of new features and retire support for some older platforms. For the currently implemented changes (not yet released at the time of writing) see GitHub release notes, and the complete list of v3 issues/features.

Some notable additions include some new toggle types to enable scenarios such as automatically enabling a feature once the assembly version number meets or exceeds a specific version and decorators to allow a toggle to default to on or off if the underlying toggle errors in some way, such as missing configuration or network error while retrieving the toggle value from a remote source such as SQL Server.

Once v3 development is complete it will be available via NuGet.

New Pluralsight Course - Better .NET Unit Tests with AutoFixture

My new Pluralsight testing course was just released: Better .NET Unit Tests with AutoFixture: Get Started.

AutoFixture is an open source library that allows the simplification of automated .NET tests. It allows for the creation of “anonymous” test data. This is data that is required for the test to execute, but where the exact values are unimportant.

AutoFixture is not dependent upon any specific testing framework, so can be used with xUnit.net, NUnit, MSTest, etc. There are some additional extensions for specific testing frameworks such as xUnit.net that allow further reductions in unit test setup code.

For more info check out the GitHub site or the Pluralsight course.

If you like AutoFixture be sure to give open source thanks to Mark Seemann.

Using AutoFixture To Generate Anonymous Test Data in Web UI Automation With BDDfy and Seleno

I’m currently working on an AutoFixture Pluralsight course and it got me thinking about using it to generate anonymous test data when writing automated UI tests.

The basic premise is that in addition to using AutoFixture to generate unit test data, it can also be used to populate UI elements where the specific data values are unimportant.

If you are unfamiliar with BDDfy and Seleno, they are part of the TestStack project.

BDDfy allows tests to be written and to produce business readable documentation. Seleno allows the automation of web browsers using Selenium and strongly-typed page object models.

Example Scenario

Imagine that we have an (ASP.NET MVC) web site that allows the addition of members of the royal family.

image

If we wanted to test different king/queen names (but didn’t care about the Regnal number) we could start off by defining some strongly typed (Seleno) page object models:

public class HomePage : Page<AddRoyaltyModel>
{
    public CreatedPage CreateRoyalty(AddRoyaltyModel royal)
    {
        Input.Model(royal);

        return Navigate.To<CreatedPage>(By.Id("Create"));
    }
}

public class CreatedPage : Page
{
}

 

(all the examples in this post are fairly quick-and-dirty to demonstrate the AutoFixture involvement)

 

Next we can write some example in BDDfy (using xUnit.net as the test framework):

public class AddRoyaltyTests
{
    private HomePage _home;
    private CreatedPage _confirmationPage;
    public string Name { get; set; }
    public string Number { get; set; }

    [Fact]
    public void ShouldAddRoyaltiesWithDifferentNames()
    {
        this.Given(x => GivenIAmStartingANewRoyalAddition())
            .And("And I have entered <name> as the royalty name")
            .And("And I have entered <number> as the regnal number")
            .When(x => WhenIChooseToAddTheNewRoyal())
            .Then(x => ThenIShouldSeeAConfirmationOfTheNewRoyalHavingBeenAdded())
            .WithExamples(new ExampleTable("name", "number")
                          {
                              {"Richard", "I"},
                              {"Henry", "I"},
                              {"Elizabeth", "I"}
                          })
            .BDDfy();            
    }



    private void GivenIAmStartingANewRoyalAddition()
    {
        _home = Host.Instance.NavigateToInitialPage<HomeController, HomePage>(x => x.Index());
    }        

    private void WhenIChooseToAddTheNewRoyal()
    {
        var royal = new AddRoyaltyModel
        {
            Name = this.Name,
            RegnalRomanNumeral = this.Number
        };

        _confirmationPage = _home.CreateRoyalty(royal);
    }

    private void ThenIShouldSeeAConfirmationOfTheNewRoyalHavingBeenAdded()
    {
        Assert.Equal("Created ok", _confirmationPage.Title);
    }
}

Notice in the preceding code that even though we don’t care about the Regnal number we are still supplying it in the examples. We could just set it manually to a hardcoded value, and in this simple example that might be ok, but if we had a form with many fields then this  will introduce extra work and may make the test less “refactor-safe”.

The following code shows the removal of the Regnal name/number:

public class AddRoyaltyTestsUsingAutoFixture
{
    private HomePage _home;
    private CreatedPage _confirmationPage;
    public string Name { get; set; }

    [Fact]
    public void ShouldAddRoyaltiesWithDifferentNames()
    {
        this.Given(x => GivenIAmStartingANewRoyalAddition())
            .And("And I have entered <name> as the royalty name")
            .When(x => WhenIChooseToAddTheNewRoyal())
            .Then(x => ThenIShouldSeeAConfirmationOfTheNewRoyalHavingBeenAdded())
            .WithExamples(new ExampleTable("name")
                          {
                              "Richard",
                              "Henry",
                              "Elizabeth"
                          })
            .BDDfy();            
    }

    private void GivenIAmStartingANewRoyalAddition()
    {
        _home = Host.Instance.NavigateToInitialPage<HomeController, HomePage>(x => x.Index());
    }        

    private void WhenIChooseToAddTheNewRoyal()
    {
        var fixture = new Fixture();

        // Use AutoFixture to create anonymous data for all properties except
        // name which is set to the BDDfy example value
        var royal = fixture.Build<AddRoyaltyModel>()
            .With(x => x.Name, this.Name)
            .Create();

        _confirmationPage = _home.CreateRoyalty(royal);
    }

    private void ThenIShouldSeeAConfirmationOfTheNewRoyalHavingBeenAdded()
    {
        Assert.Equal("Created ok", _confirmationPage.Title);
    }
}

In this version, AutoFixture’s Build method is being used to automatically generate test data for all the fields, except the royal name which is set to the name(s) specified in the BDDfy examples.

Running this test results in the following automation:

SelenoAutofixture

 

And produces the following HTML BDDfy report:

image

Open Source Thanks

In a previous post (5 Ways to Contribute to Open Source - It’s Not All Code) I mentioned the simplest way to be involved in open source is to simply Tweet about the project or by saying thanks to the creator/contributors. In the post i said “Most open source authors don’t get paid, saying thankyou is not only nice but is good encouragement for the authors to keep the project going”.

I’d like to propose the hashtag #opensourcethanks – it would be great to see the Twitter search for this hashtag fill up with thankyous :)

If you’re benefitting from an open source project, take a minute to send a thankyou Tweet.

Fixie - A Convention-based .NET Testing Framework

Fixie is a relative newcomer to the .NET testing framework space. It throws away the idea of marking elements of test code with attributes in favour of a conventions based approach.

At a high level, what this means is simply naming things in test projects following a defined default (customized conventions are also supported) convention.

A Fixie test class with a single test inside it would look like the following, notice the lack of attributes and even using statements.

namespace MyApplication.Tests
{
    public class SomeClassTests
    {
        public void ShouldDoSomething()
        {
        }
    }
}

After building the test will now show up in Visual Studio Test Explorer as the following screenshot shows.

Visual Studio Test Explorer showing Fixie Test

Fixie knows this is a test because it matches the default conventions that come out of the box.

Fixie knows that this is a test class because it ends with “Tests” and it knows that the method is a test because it’s a public void method.

If these default conventions are not suitable for your project you can create your own custom conventions to customise the test discovery. There’s also a lot more to custom conventions, such as customising the test execution lifecycle and creating data-driven tests.

To learn more about Fixie, check out the docs or my Introduction to Fixie Pluralsight course.

about jason

My Bio Photo

Jason Roberts is a Journeyman Software Developer, Microsoft MVP, writer, Pluralsight author, open source contributor and Windows Phone & Windows 8 app author.

He holds a Bachelor of Science in computing and is an amateur music producer and landscape photographer.

MVP Logo

Pluralsight Author Badge

Sign up for the Don't Code Tired Newsletter

Disclaimer
The opinions expressed herein represent my personal opinions and do not represent my employer's views in any way.

© Copyright 2015, Jason Roberts