Get ready, we have a packed summer full of great topics at the Chicago Visual Studio ALM user group! Be sure to join us in beautiful downtown Chicago at the Aon Center in June for this next session on how to improve your user acceptance testing practices using SpecFlow! Be sure to pre-register on our user group site so we can get you entered into the security tool, and please do keep us posted if you have to cancel! We don’t like throwing away food and it helps me to order the right amount.
Imagine a project you’ve worked on in the past. Whether or not you or your organization makes use of Agile processes, you probably spent a good deal of time going back and forth with business stakeholders on the fine detail of how the software you’re building should behave. It’s possible you had to dedicate effort simply to producing a demo that the business will appreciate and understand. It’s even more likely that at some point, you and the business had disagreement(s) on whether something was “working”, “finished”, or “done”. Those types of discussions can leach away at your team’s time, expend effort, and impact morale as well as create tension between development teams and the business.
Now imagine if you could instead pour that blood, sweat, and tears into developing your application’s functionality. Imagine a scenario where new features are authored test-first, by non-tech staff in a plainly understandable, shareable, and versionable text format. Imagine a situation where the same set of specifications can be shared to drive a browser-based test suite at the same time that the specifications drive an integration test suite. These are the types of scenarios that tools like SpecFlow are particularly well-suited to address.
Unit tests are great for verifying atomic pieces of software functionality, but they are very poor at capturing and communicating specifications at any other resolution than fine-grained. They’re also completely useless to a non-technical user attempting to understand a system’s functionality.
This is where acceptance testing enters the picture. Although commonly classified as BDD (Behavior-driven design), tools and frameworks like SpecFlow serve to bridge the gap between proving the correctness of a piece of code from the inside, micro perspective and the correctness of an application as a whole from the outside perspective.
In this talk, we’ll go over what acceptance testing is, when it should be used, and how to add acceptance testing into an existing application using SpecFlow. We’ll also talk a bit about DSLs (domain-specific languages), the pyramid of returns vs. effort when it comes to different types of testing, techniques for authoring and designing tests and bindings, and finally, because this *is* a group about ALM, how to integrate SpecFlow into a CI environment and why you or your organization should do so.
If attendees wish to follow the demo on their laptops, they can save time by pre-installing the VS tooling for SpecFlow – http://specflow.org. The download there adds some tooling support within the VS IDE, and is not needed to run SpecFlow.
Josh Elster is the founder and principal of his independent production and consulting company, Liquid Electron. With clients ranging from small media design shops to multi-billion dollar corporations, Josh’s experience spans a number of different sectors, projects, and roles. In February of 2012, Josh joined the community advisors board for Microsoft’s Patterns and Practices team for the CQRS journey project (http://cqrsjourney.github.com), as well as being a contributor. Like the common cold, but without the whole being ill aspect, it is Josh’s hope that he can infect others with his passion for software development. When not serving as Patient Zero, Josh can be found reading, playing video games or guitar, or coding. His website can be found at http://www.liquidelectron.com. His Twitter handle is @liquid_electron. His most recent demonstration project, the PostcardApp, can be found at http://www.postcardsfromskyrim.net.