Wire up the Specflow step definitions with a Coded UI test methods

This post is the third edition of the Specflow with Coded UI Tests series

So our project now has the Specflow Feature that describes the Calculate Addition feature and our Coded UI Recordings that contain our actions of inputting a value into our calculator. Now we just need to wire the two together. Specflow does this by using a Step Definitions class. Basically that class contains a bunch of methods that is bound to generated test via a series of specflow attributes, Given, When a and Then. When the test runs it matches the wording of the Scenarios Step with the wording in the specflow Attributes

 

image

When you run your feature without creating the step definitions specflow fails the test as Inconclusive. In the test results specflow will generate the structure of step definitions that it was expecting for the test. This is a great starting point for your step definitions

image

Copy this into a new code file and you end up with

namespace SpecflowAndCodedUI.StepDefinitions
{
    using TechTalk.SpecFlow;

    [Binding]
    public class StepDefinitions
    {
        [Given(@"I have entered 50 into the calculator")]
        public void GivenIHaveEntered50IntoTheCalculator()
        {
            ScenarioContext.Current.Pending();
        }

        [Given(@"I have entered 70 into the calculator")]
        public void GivenIHaveEntered70IntoTheCalculator()
        {
            ScenarioContext.Current.Pending();
        }

        [Given(@"I press add")]
        public void GivenIPressAdd()
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"the result should be 120 on the screen")]
        public void ThenTheResultShouldBe120OnTheScreen()
        {
            ScenarioContext.Current.Pending();
        }

        [When(@"I press equals")]
        public void WhenIPressEquals()
        {
            ScenarioContext.Current.Pending();
        }
    }
}

Now we can clean this up a bit. Looking at out Specflow feature we can see that some of the steps are basically the same thing except for the value being tested. This is the same for both scenarios. We can make the step definition methods more generic and allow it to take parameters. To do this remove the 50 from Method name and replace the 50 in the Attribute’s string with “(.*)” minus the quotes. This tells specflow that any string in that position of the step will be passed into the method as a parameter. To account for this we also have to create a string parameter for the method. The result looks like this

        [Given(@"I have entered (.*) into the calculator")]
        public void GivenIHaveEnteredIntoTheCalculator(string input)
        {
            ScenarioContext.Current.Pending();
        }

Specflow will then reuse this step definition for the following steps

image

If we do the same thing for the other method then we end up with a class that looks like this.

namespace SpecflowAndCodedUI.StepDefinitions
{
    using TechTalk.SpecFlow;

    [Binding]
    public class StepDefinitions
    {
        [Given(@"I have entered (.*) into the calculator")]
        public void GivenIHaveEnteredIntoTheCalculator(string input)
        {
            ScenarioContext.Current.Pending();
        }

        [Given(@"I press add")]
        public void GivenIPressAdd()
        {
            ScenarioContext.Current.Pending();
        }

        [When(@"I press equals")]
        public void WhenIPressEquals()
        {
            ScenarioContext.Current.Pending();
        }

        [Then(@"the result should be (.*) on the screen")]
        public void ThenTheResultShouldBe120OnTheScreen(string expectedResult)
        {
            ScenarioContext.Current.Pending();
        }
    }
}

Wiring up the Step Definitions with the Coded UI Test Methods

Now that we have our step definitions sorted we need to implement the actual test using the Coded UI Test API. If you configured your project using this specflow wiki article the custom generator will make sure the Playback engine is initialized. This is done by calling the Playback.Initialize(). If the project is not set up using this process you will receive some errors.

Then we just call the methods via the static UI Map manager class we created, add any scenario setup and teardown code and we end up with this class

namespace SpecflowAndCodedUI.StepDefinitions
{
    using SpecflowAndCodedUI.UI.UIMapLoader;
    using TechTalk.SpecFlow;

    [Binding]
    public class StepDefinitions
    {
        [BeforeScenario()]
        public static void PrepareForTest()
        {
            Calculator.General.LaunchCalculator();
        }

        [AfterScenario]
        public void CleanUpTest()
        {
            Calculator.General.CloseCalculator();
        }

        [Given(@"I have entered (.*) into the calculator")]
        public void GivenIHaveEnteredIntoTheCalculator(string input)
        {
            Calculator.Standard.TypeAValue(input);
        }

        [Given(@"I press add")]
        public void GivenIPressAdd()
        {
            Calculator.Standard.ClickAddButton();
        }

        [When(@"I press equals")]
        public void WhenIPressEquals()
        {
            Calculator.Standard.ClickEqualsButton();
        }

        [Then(@"the result should be (.*) on the screen")]
        public void ThenTheResultShouldBe120OnTheScreen(string expectedResult)
        {
            Calculator.Standard.AssertTheResultExpectedValues.InputLableValueDisplayText = expectedResult;
            Calculator.Standard.AssertTheResult();
        }
    }
}

In this class we are reusing both the Specflow Steps and the CodedUI Methids such as TypeAValue. Note the assertion is a little different to the way we use TypeAValue. In Record your Coded UI test methods i suggested Moving the code into the code behind so we can edit it allowing us to pass a string to that method. The way i am calling the Assert is the way you would pass data to a method that has not been moved into the code behind for editing. This allows you to continue using the Coded UI Test Editor instead of managing the code yourself.

Source code for this series can be found here

SpecFlow 1.6

SpecFlow 1.7


Advertisements
  1. #1 by Alexander Kormachev on June 25, 2011 - 8:22 am

    Good example, Ryan, I had some difficulties to start testing at first. I placed SpecFlow stuff to a Unit Test project, which was not a good idea:). SpecFlow stuff should be place to some Coded UI Test project to start Coded UI Test within itserf. I prepared simple example of solution layout for SF and CUIT, maybe it would be interesting for someone: http://ixkormachev-sf-and-cui.blogspot.com

  2. #2 by Max Claus Nunes on January 15, 2013 - 3:14 pm

    I was a bit confuse about the And Attribute. Your post helped me a lot. Thanks!

  1. Record your Coded UI test methods « Ryan Burnham's Blog
  2. BDD UI Automation with Specflow and Coded UI Tests « Ryan Burnham's Blog
  3. Warewolf Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: