In July of 2018, I gave a talk at KCDC titled SpecFlow: Moving Beyond the Basics. Afterward, I changed the title to Scaling SpecFlow to more accurately reflect the topic. You can find the updated slide deck at https://joebuschmann.github.io/scaling-specflow. Over the next few weeks, I created a series of posts, one for each section of the talk, for those of you who perfer blog posts to slide decks. This page aggregates these pages in one place and takes you through each one in order. Read more

The SpecFlow runtime comes with a little known command line utility aptly named specflow.exe. You can find it in the tools directory in the SpecFlow NuGet package (ex: [project]/packages/SpecFlow.2.3.2/tools). This humble tool can be used to regenerate SpecFlow unit test classes, create test execution reports for NUnit and MSTest, and generate a step definition report. The most useful of these is the step definition report. As the number of features grows, scenarios and bindings are going to get lost in the day-to-day scrum of software development. Read more

As of SpecFlow version 2.0, you can run scenarios in parallel. This means faster execution times and faster feedback in your continuous integration process. Memory Isolation To enable parallel execution, you must use a test runner that supports it. Available runners include NUnit 3.0, xUnit 2.0, and the SpecFlow+ Runner (specrun). Specrun is a commercial product, but it has advanced features like memory isolation via an app domain or process. NUnit and xUnit don’t support memory isolation, so they requre your tests to be thread safe. Read more

As your application grows, your SpecFlow test suite needs to grow with it. Reusable bindings are essentional to prevent your code from becoming a bloated mess. Fortunately, the SpecFlow runtime has reusability in mind with a built-in inversion of control (IoC) framework and step argument transformations. With these features you can create reusable bindings that make test creation more productive. Problems with Inheritance Before digging into IoC, I’ll take a moment to cover why you shouldn’t use inheritance in your bindings. Read more

The Gherkin DSL defines data tables as a way of passing a list of values to a step definition. Gherkin tables use the pipe character | to delimit column names and values. They’re easy to read and understand by both business and technical people. While they work great in Gherkin, tables don’t translate well to strongly typed .NET languages. They are converted to an instance of the Table type in SpecFlow bindings. Read more

[Gherkin] is a Business Readable, Domain Specific Language that lets you describe software’s behaviour without detailing how that behaviour is implemented. - Gherkin Wiki These Gherkin best practices were originally included in an early draft of a talk I gave on SpecFlow. Ultimately, I took them out because they didn’t fit well with the topic, so I put them into a blog post. Table values should be atomic Bindings that take a table argument will almost always convert the table to a C# object for easy manipulation. Read more