This post is the first edition of the Specflow with Coded UI Tests series
To create a Specflow feature file first we will need to set up our test project to be able to support specflow tests.
- Install Specflow from http://www.specflow.org/. Specflow is an open source project, the source and wiki is located here https://github.com/techtalk/SpecFlow. The wiki is a good source for setting up project as some projects require different configuration. Specflow also supports NUnit but for this sample i will be using MSTest.
- Configure your Test Project to use Specflow. To do this follow the instructions listed on the Specflow wiki https://github.com/techtalk/SpecFlow/wiki/Using-SpecFlow-with-CodedUI-API
- Installing Specflow creates a Specflow Item Templates. Add a new Specflow Feature File called CalculateAddition.feature
The feature file is written following a language designed for readability called Gherkin. This allows you to express exactly what you scenario/feature is testing without requiring loads of programming knowledge. By doing this it also allows people like the Quality Assurance team or Business Analyst to write the features. These members normally have a better understanding of the requirements and what needs to be tested to ensure this feature is successfully implemented. Specflow then uses this feature file to generate a test class using the provider selected in the Config file, in this case MSTest. Gherkin is also used in other Business Driven Development frameworks.
- Write our Feature using the Gherkin syntax. This syntax is pretty simple to get started. All it is is a consistent format starting with key works such as Given Then and When. The feature definition only needs to start with “Feature: “ and then the name of the feature. The following lines are used to describe the feature but a common scrum like format would look like this.
This format makes it clear what the feature is and why it is being or has been implemented. To demo this i will uses the Windows Calculator.
In this cause the As a user line is a bit difficult to explain due to the simplicity of this application. A normal application may have different identities that their features are aimed towards. You might have a General, A Receptionist and an Administrator, each feature may be aimed at one or more of these identities.
- Write your scenarios using the Gherkin syntax in the feature file. In the same file we need to add the scenarios that we are testing to ensure this feature has been implemented correctly. This is where we start our sentences using key words such as Given, And, When and Then. Specflow will then expect to find a Step Definition (a method with an attribute that matches the step, I’ll go into more depth in the following post). For this feature we are testing 2 scenarios using 2 different methods.
The first scenario is a very simple scenario that only tests one variation of input data. The second scenario is a data driven scenario, it runs the scenario for every iteration in your examples table. Note that these scenarios are very granular which is required for this sample but normally i would write the scenario’s in a more abstracted way. Writing steps that talk about clicking buttons usually makes it hard to implement and doesn’t create very reusable steps . As an example think of a scenario testing the Standard users permissions of an application preventing them from modifying user permission. I would create a scenario that looks like this.
By doing this our feature becomes more flexible. The step “Given i am logged in as a standard user” could be reused in other features and if the method of logging in changes we only need to change the step definitions (the actual code that runs the test). It is up to the person wiring up the step definitions to decide what the best way to do this is. If the steps were more granular as in “Click the login button” it would be harder to reuse and maintain these features. It would also create readability issues of your feature files in complex scenarios which goes against what is great about the Gherkin format, that the every day person can understand it.