As a tester in a Scrum development environment when I heard about Specflow and Behaviour Driven Development I started to wonder if we could use the Specflow Gerkin format to specify our acceptance criteria for a User Story and then be able to wire this up to a coded UI Test to prove that we have actually added this feature and to ensure that it will not break in the future. After a bit of research and a good understanding of Coded UI test and Specflow I found it actually wasn’t that hard to do. So why would I do this?
- Specflow tests are normally aimed around the ViewModel layer; this is fine if you’re using a good architecture but what about older legacy products.
- Normal Specflow tests do not test exactly what the user will experience.
- Unfortunately Coded UI Tests have been known to be brittle and this is defiantly something you need to be aware of. With older technology Coded UI Tests uses MSAA (Microsoft Active Accessibility) to find property values of a control. From my experience this can be a bit flaky however the .net version should be a lot better. If worst comes to worst you can write a technology plugin for Coded UI Tests to help it out. A strict project structure can help to limit how much work needs to be done when the UI Changes. For example record actions in small chunks, this makes them flexible and means that you won’t have to rerecord much it the UI Changes.
So there are both pros and cons about using UI Tests for Acceptance Tests but the one good thing is what you test at the UI Level will be what the user sees.
How to create an Automated UI Specflow Feature
This sample assumes you have a good understanding of Specflow and Coded UI Tests
- Create a Specflow Feature file
- Record your Coded UI test methods
- Wire up the Specflow step definitions with a Coded UI test methods
Source code for this series can be found here