Introducing SpecFlow

Philly .NET Code Camp 2010 was particularly timely, being in conjunction with the Visual Studio 2010 launch. There were 10 different tracks, with numerous well-known speakers and many exciting new .NET features. Despite all of that, one of the more low-profile talks, by Tony Nguyen, on Behavior Driven Development, proved to be the most exciting to me. This talk on BDD and the relatively new product SpecFlow draws heavily on concepts pioneered in the Ruby world through the Cucumber BDD framework.

I had been unconvinced about the full value of BDD prior to this. I could see potential benefits as part of the development process. However, I was skeptical that users, even highly motivated users that are part of an agile process, would be interest in seeing test results. With SpecFlow, instead of just seeing test results as output, quality assurance or end users can write out requirements.

The approach SpecFlow takes is requirements first. The requirements are written in the natural language Gherkin. Conventions are then use to determine the names of tests that should be written. Instead of being test-first, it is requirement first. Running the test suite will confirm or deny the existence of individual test cases and whether they return the proper result. Requirements writers can write cases in notepad and developers can run test suites integrated into Visual Studio. I haven’t provided any details of the Gherkin language but Tony’s presentation, available here, is one good place to start.

There are some immediate questions that are still worth considering before jumping in using SpecFlow. One important question to consider is that given SpecFlow is a fairly new open source project, will it continue to be actively maintained? Another big question is, will there be end-user buy-in into writing requirements in this fashion? Tony has had some success with end users but reports, after less than a year of development with BDD on his most recent project, less than 100% adoption. Organizational culture and management support will affect adoption greatly. Finally, BDD emphasizes integration style tests. How should unit testing be combined, if at all, with BDD tests? In Tony’s case, there test cases are most done in SpecFlow but unit test cases have been written too by some team members.

Turbo-charge your .NET application – upgrade to .NET 4.0

Even if you aren’t planning to take advantage of any of the new features in the .NET 4.0 Framework, performance alone can justify the upgrade. I recently spent a “Day of Performance” with John Robbins at the April 2010, Wintellect Devscovery conference. He estimates that applications should see a 5-10% increase in performance. This is due to improvements in garbage collection and within the Common Language Runtime (CLR).

Prior to .NET 4.0, garbage collection took over execution within your application. This meant that while garbage collection was running, your code wouldn’t be. In .NET 4.0, garbage collection can now occur in a background thread. Of course, it is always wise to address performance by cutting down on the number of garbage collections that are necessary.

Two performance boosts stand out in the .Net CLR: reflection and StringBuilder appending. Although already fast, Robbins’ performance metrics show that StringBuilder appending is three times as fast. Reflection binding and invoking are also three times as fast. Considering how slow reflection is compared to normal method invocation, this increase is huge. Even if you aren’t directly performing reflection or using a StringBuilder, the NET FCL code uses these classes as building blocks. I have run Robbins’ test suite and encountered the same results on my own PC. I have not directly included the test suite results or test code due to intellectual property concerns.