If you’ve read my post on the value of automated UI testing, you’ll know that I value it over Unit Testing. That’s not to say Unit Testing isn’t important, just that there is greater business value in Automated UI testing, if you can get it to work for you.
In this post I’m going to describe how SpecFlow could be used to achieve this with WPF applications. I’m not going to pretend that my small example here is going to solve problems of applying this to large projects, but hopefully it will provide a start point, a trigger to further investigation and establishing some best practices, appropriate for the product being tested.
Firstly then, a quick description of my Demo App. If you’ve read some of my other posts you will be familiar with the groundbreaking WPF media player. It allows user to select a folder, display the media in that folder and play that media:
Unit Tests in VS
Unit Testing is now an integrated part of Visual Studio and has been for a number of years. Everyone reading this is no doubt very familiar with this, so I won’t venture to explain it. Suffice it to say, that ideally we want to do UI testing in a testign framework that is well supported in Visual Studio. SpecFlow supports both MSTest as well as nUnit.
Introduction to Gherkin
Specifying User Acceptance Criteria for stories is always in danger of being ambiguous. Capturing them in a standardised notation often helps make thes acceptance criteria more explicit. Whilst at Nokia, our sprint planning sessions involved the PO describing the story and then the team defining UACs as Gherkin scenarios.
Gherkin is a simple notation based on scenarios that can be written using Given – When – Then clauses. Given being the system state, When being a user action and Then being the outcome. Gherkin is ‘Business Readable’, so can be fully understood by the PO and the business.
Introduction to UI Automation
Microsoft have helped matters in testing UI written in WPF through their UI Automation API. This API enables us to drive WPF applications and check content of controls. Again, I am not going into too much detail as there is more than enough elsewhere and to be honest I have only recently started looking at the UI Automation API. The reason I bring it up here is that we need a way of pulling Unit Tests with MS Test, UI Automation to drive the UI and Gherkin to allow a simple notation for defining Scenarios and ultimately User Acceptance Criteria. Enter SpecFlow….
Introduction to SpecFlow
Lifted straight from their website: “SpecFlow aims at bridging the communication gap between domain experts and developers by binding business readable behavior specifications to the underlying implementation.”
Specflow is designed for .NET, supports MS Test and integrates with Visual Studio. On initial inspection, this looked like what I had been looking for. I shall now go through an example of writing tests using SpecFlow for the application described above. There is obviously plenty more information on the various product web sites so I would advise going there rather than copying my example. This example is here to fire the imagination, if that is what you are after.
Add a feature
We are starting from an empty Test Project in Visual Studio and adding a feature is as simple as selecting the “SpecFlow Feature File” on “Add New Item”. The dialog also includes Event Definition files and Step Definition files, which we will use later.
This adds a new .feature file which contains a basic feature and scenario. I edited this to add a couple of scenarios which should be self explanatory. After all, that is the purpose of Gherkin:
Here you can see the Scenarios as Give, When, Then steps. Once this file has been added the tests will build and run as inconclusive. Each scenario forms a test case. SpecFlow does some magic in generating the code for the feature file. What must be done now is the writing of any setup / tear down code and methods for each step.
Add Event Defs
An event definition file can be added which has methods for executing code at various stages during the running of scenarios and tests. In our case we just want to kick off the application on each feature test and kill it after:
Add Steps for feature
The bulk of the coding must be done in the Steps Code. Taking the example of the first scenario we want to write 3 steps for the given / when / then clauses in the gherkin:
As you can see, SpecFlow uses attributes to match steps to methods, really very simple. Most of this code is the neccessary boilerplate for UI Automation, which leads us on to how we might deal with this in a real application
The first thing I noticed, which was really to do with the UI Automation, was the amount of boilerplate that was needed. In a real application, this would get significantly more complex than this exmaple, very quickly. Ideally each View would have a UI Automation wrapper written for it that would encapsulate the UI Automation code, allowing the test developer to call single methods to perform opearions on the UI and to check values in controls. I am guessing that at this point it would be worth investigating F# to do this, as it seems that a more functional language may help in this. Any comments on that will be gratefully recieved.