In a previous post, I covered scoped bindings in SpecFlow and ended with an example of how not to use tags. In this post, I’ll cover the “right way” and demonstrate how to avoid coupling features to step definitions. But first, a quick primer on tags. What Are Tags? Tags are used in Gherkin to mark features or scenarios. They begin with the @ character in Gherkin, but in step definitions the @ is removed. Read more

One nice aspect of SpecFlow is the ability to scope bindings by feature title, scenario title, or tag. Normally bindings are global to the project, but a binding’s scope can be restricted using the Scope attribute. I like to think of it as similar to the private and public class modifiers in C#. Consider the Gherkin below. It is a single feature with one scenario and two tags. One tag is at the feature level and the other at the scenario level. Read more

I’ve seen some pretty bad SpecFlow code. Code that seems to violate every good practice out there. Poor reuse. Copy and paste everywhere. Test code is the hotel room of the software world. People are sloppier and more careless than they otherwise would be. I’m not sure why that is. Perhaps because tests are not seen as “real code”. But as a testing code base grows from dozens to hundreds to even a thousand or more test cases, having well-factored composable SpecFlow steps becomes critical. Read more

The C# language’s using alias directives or namespace and type aliases provide a way to disambiguate between namespaces or types with the same name. For example, both the System.Net and Nancy libraries have a type named HttpStatusCode. If you happen to import both namespaces in a file, then the types need to be fully qualified or else the compiler will fail with the error: ‘HttpStatusCode’ is an ambiguous reference between ‘Nancy. Read more

We all have those days where we spend hours trying to solve a seemingly simple problem only to smack ourselves in the head when we finally figure it out. Missing quotes, forgetting to flush a StreamWriter, etc. If only we could get back all the wasted time. Well, this week I wrestled with more gotchas than usual. Below are the ones that burned most of my time. Streams Don’t forget to flush a StreamWriter when you’re done. Read more

If you’ve been in the .NET world for any length of time, you’ll eventually come across someone who claims String.Empty performs better than "". I was always skeptical of this claim because this scenario seemed like something the compiler could optimize. And because the .NET runtime manages string literals in an intern pool, my guess was they would both point to the same value. That’s what I suspected anyway but didn’t have any proof. Read more