As you might know, the SpecFlow v2 pre-release has been published. We have been trying to put together a detailed list of changes for SpecFlow v2: http://go.specflow.org/versionhistory. There is also a short summary on the SpecFlow website. So this is my own top 3. A subjective one.

Update: The final v2 has been released on January 27, 2016. Check out the necessary upgrade steps and the updated roadmap. I keep posting about features and details of v2. You can find these posts by filtering for the SpecFlow v2 tag.

1. Project upgraded to .NET 4.5

I’ve been asked by many people over the last years, what will be the new stuff for SpecFlow v2, as it looks “complete”. And at some level it was complete indeed. There are a few annoying thing in the Visual Studio integration, but the core product worked relatively well. If I remember well, .NET 4 was already out when we released SpecFlow 1.9, but it was not used by that many projects yet, so we decided to go for a solution based on .NET 3.5 (ie the .NET 2 runtime), so that we can support both platforms without too much efforts. We cut off the support of some features of .NET 4 with this decision (e.g. the dynamic support), but at that time this limitation did not look very painful.

I started to worry when the first C# asynchronous programming constructs came out. I don’t really know why, but I like this way of thinking. For me, who grew up in the classic imperative style programming, everything that needs my brain work by completely different rules are challenging and fun (same for functional programming and strangely also with the messaging model of objective-c). So when I have saw this coming, I felt that this also needs a different way of thinking for your tests.

Async support has not been added to v2 yet… But we can do it now.

2. Parallel test execution

This is my other favorite. I have been working on SpecFlow+ Runner for a long time. With that runner you were able to run your tests in parallel – every test thread isolated to a separate AppDomain. When we started to use this in our projects, I realized that it is not that easy to make an average SpecFlow integration test parallelizable. So we worked hard and in the most of the cases we were able to drop the execution time to ~40%, even on a single machine. As I learned how you can plan your project to be parallelizable, the AppDomain isolation started to be a limiting factor. It simply takes too much resources for running the tests in many (>10) threads. So I was happy that we’ve got a request from a company to develop the necessary infrastructure into SpecFlow so that we can run the tests parallel even within an AppDomain. So it is time to step to the next level for learning how to make parallel-ready tests!

v2 supports in-appdomain parallel execution with NUnit 3 and xUnit 2. TechTalk also plans to add this feature to SpecFlow+ Runner.

3. The new Gherkin3 parser

Ok, I know. For many of the SpecFlow users, a new parser – as long as it parses your feature files – is not such an exciting news. But for me, SpecFlow started with the parser. 6 years ago, on that night when I wrote the first prototype of SpecFlow, I wanted to play with the new language workbranch tool of Microsoft, the project codename “Oslo” and with its DSL grammar… There were several other parsers used by SpecFlow and the other Cucumber-family tools, and we felt that we need a new, standardized cross-platform parser. So that regardless of which tool you use, your feature files should be fully compatible. This is the Gherkin3 project, that I supported with a special cross-platform parser generator, called Berp. Now Berp generates the gherkin parser for Java, Javascript, Objective-C, Ruby, Python, Go and of course .NET for several thousands of users around the world.

There are a few small improvements for the SpecFlow users still. For example you can also wrap the multi-line text step arguments (called doc-string) not only with triple quotes (“””) but also with triple apostrophes (”’). Isn’t it cool? And also you can… let me think. Anyway. But it is definitely much-much faster and uses much less memory, so you should see a performance improvement when re-generating the files. And just like with the .NET upgrade, this opens new possibilities, especially for the Visual Studio integration. Maybe we will be able to run the SpecFlow tests without the code-behind file?

(I remember now: in v2 you can put a newline into a table cell with “

” and also add a pipe with “\|”. If you need a backslash, use “\\”. Have fun!)

—

You can learn and practice the new features of SpecFlow v2 on my SpecFlow course (official SpecFlow course). See the upcoming courses or book a private in-house course!