Trying out BDD With SpecFlow and Selenium - Part 1

One of the biggest things I learned when I was working as a tester at IBM is how important testing really is in applications large and small. While I've moved on to full time development the test side of my work has really never gone away. While working on updating one of the features of the Extend Health side we've decided that it would be a good time to try out some testing that hasn't been covered much.

So with that we've decided to try out some Behavior Driven Development and write some integration tests for this new feature. Since we're a .NET shop we've decided to give SpecFlow a try instead of running Cucumber straight on Ruby. Fortunately if we ever decide to switch from SpecFlow to Cucumber our features will transition directly since they are in the Gherkin format. The main reason we're trying out this Gherkin format is that it gives us a Business Readable Domain Specific Language.

The advantage that this would buy us is that we could document the sites features in a way that both the business development team could read and write features in a way that we in development could directly write tests against them. This also helps us in development because we have a solid list of features we know that we need to implement and that we should be less likely to either break that feature or miss it altogether. This is one thing that Unit Tests just don't really buy you. It would be easy enough to write a suite of Unit Tests that don't cover the actual feature itself as described by the business.

So lets get to what a test in SpecFlow looks like.

Feature: Share this post
    In order to increase traffic to the blog to increase advertising revenue
    I want readers to share posts they find interesting

Scenario: Share on Twitter
    Given a person reading a blog post
    When they press the "Tweet This" button
    Then the Twitter popup should appear

So there we go, that's pretty simple looking right? That right there is the beauty of the Gherkin syntax to me. It is structured enough that we crazy programmer types could turn that into some tests (and we'll get there) but the business types can also read and understand what is going on here. Oh and because I think this is awesome, using Cucumber you can write this in a ton of different spoken languages.

One thing I'd like to point out though, is that while features and scenarios look really simple, I've found so far that the hardest part is writing a clear feature and scenario. Writing unit tests aren't very difficult since you break that down as much as possible. It all comes down to communication really, finding the best way to describe a feature without getting too broad or too detailed. The cucumber docs do have a really great example (scroll to the bottom) of applying the Five Whys to really decide why you want a feature and how to describe it.

So now that we've had a chance to check out the Gherkin syntax that SpecFlow uses, in my next post I'll show the actual code behind this feature and how we're starting to use Selenium to verify these features.