In the past few months I have been contacted by a number of readers who notified me that the code for my A simple SpecFlow 3 setup in Rider blog post was broken. I took me a while, but I’ve finally taken the time to fix it.
Some time ago I already looked at it and I saw that with the upgrade to dotnet core 3 there was a breaking change with SpecFlow .feature.cs file generation. Due to a change in the MSBuild pipeline, the files were not generating correctly. The following error was shown during the build of the solution.
The “GenerateFeatureFileCodeBehindTask” task failed unexpectedly.
Fortunately, upgrading to the latest version of all the packages fixed all the errors. Thank you SpecFlow team!
I’m keeping this specifically simple and small. As soon as the project does what it needs to, I’ll stop, because my previous articles on this explain the rest (which still works) in more detail.
I’m just creating a new solution from Rider and adding a Unit Test Project with the xUnit framework. If you’re unaware, I’m a big fan of the xUnit framework. Then I added 3 Nuget packages:
At the time of writing this article, all these packages have version 3.1.74.
When I want to install the SpecFlow.xUnit package, Nuget complains that xUnit is not the latest version and I have to update from 2.4.0 to 2.4.1. I took the opportunity to use Riders awesome Upgrade All Packages In Solution. Quick and easy.
Now that everything is installed, I just insert a File and name it SomeTest.feature. I type away and create a simple SpecFlow file. I could now build and run the test, but out of habbit, I create a SomeTest.steps.cs file and put in the basic Binding and Scope attributes above the class.
Then I run the tests and check the output.
As you can see on the right part of the output pane, it still works as in my earlier article and I can just copy out the relevant parts for my test setup. After I flesh out the test a bit, I run it again and get a green check.
I did exclude the generated *.feature.cs as it contains an unknown element, but does compile. The error does show the annoying red line below the file hierarchy it influences. They are not needed in the project (or the git repo, I excluded them via the .gitignore) to make the tests run. They are being included during the build step anyway.
SpecFlow 3 works very nicely with DotNet Core 3.x and the Rider IDE. It’s a great time to be a (DotNet) coder!
A while ago, I wrote about using SpecFlow with JetBrains IDE Rider. Recently, SpecFlow updated their version to 3.0 and it brings some different behaviour with it. After using it for a while, I really like the new flow.
The biggest benefit of the SpecFlow.Tools.MsBuild.Generation nuget is that I don’t need to set up a file writer anymore. I do need to update the .csproj file to include some configuration. The whole process is nicely documented on the SpecFlow site, but I’ll give the basics here.
First, right click on the test project and choose Edit > Edit MyProject.csproj option. Then just paste in the next bit of XML:
<!-- include any generated SpecFlow files in the compilation of the project if not included yet -->
<Compile Include="**\*.feature.cs" Exclude="@(Compile)" />
The old SpecFlow version can add configuration tags in the .csproj file: <Generator>SpecFlowSingleFileGenerator</Generator>. They can easily be replaced by doing a search and replace (ctrl+h in rider) and using this regex to find all of them: \n[ ]+SpecFlowSingleFileGenerator.
Save the .csproj file and just build the project. The .feature.cs files will be generated next to the .feature files. You can include them in the project, but the build server will update the generated files when it builds the project anyway. So you don’t need to include the .feature.cs files in the project anymore if you don’t want to.
Happy coding and keep those tests green!
Update: I got some feedback that it isn’t intuitive to find the Given/When/Then declarations for the .feature.cs file. All I need to do is run the tests. The method definitions appear in the test output window. If I add a new line, I just rerun the test. The test will be marked incomplete with the new method signature in the test output window. All that’s left to do is to copy and paste the signatures into the right file and flesh out the new method. Oh, and don’t forget to add Binding and Scope attribute on the class. I’ve forgotten that more times than I dare to admit.