You could be forgiven for rolling your eyes, initially, at the idea of BDD. In the first place, with TDD, DDD, ATDD, and BDD, the software world seems really to have loaded up on things that end in DD. Add to that some lofty promises about bridging the gap between code and domain language, and you have a recipe for scepticism.
But resist this impulse. BDD is hugely helpful, given the right tools and the right process.
The overarching aim is simple but powerful. First you express what you want the system to do in natural language, so that everyone understands. Then you match that behavior to automated tests.
It sounds simple, but the devil is in the details. Let’s explore some tools to help you achieve this, while making those details less devilish. Specifically, let’s look at some BDD tools for C#.
for QA and Development Teams
NSpec
First up, let’s examine NSpec. NSpec comes from the so-called “spec” flavor of BDD.
For a detailed treatment of “spec” BDD vs “behave” BDD, you can check out this Stack Overflow question. But briefly, behave flavored tools focus on creating actual artefacts with English language in them, and then mapping that language to code. The spec style tools have the same conversational focus, but they emphasize creating human-readable names for elements of code, such as classes and methods. And on that spectrum, NSpec is, not surprisingly given its name, a spec flavored tool.
Install is easy enough. You can get started simply by installing the NSpec NuGet package, and you can integrate with your existing unit test runner. NSpec works by building up incremental context.
That’s a fancy way to say that you can divide up the various setup routines that are relevant for your testing, and assign nice human readable names to them. Most unit tests work completely context-free, in isolation, so this approach lets you rapidly construct and reuse scenarios.
MSpec
No, that’s not a typo or a repeat. This second of the BDD tools does, in fact, differ from the first, but only by a letter. MSpec is an open source, spec-flavored BDD framework.
MSpec stands for “machine specifications,” and differs by only a letter from NSpec, which draws from the curious .NET ecosystem trend to name everything N-something. Like NSpec, MSpec also uses source code semantics to allow incremental context specification. As its charter, it seeks to eliminate as much of the noise and boilerplate as possible around automated testing and leave you with just the bare and readable essentials. This framework relies on convention over configuration.
As with NSpec, you can install MSpec simply by using NuGet (it will appear as Machine.Specifications). You may also want to pair it with an assertion framework. MSpec has its own, and it can also work with popular fluent assertion library Shouldly.
BDDfy
Having looked at two spec flavored BDD tools, let’s mix it up with a behave style tool. (Though, this one is both). I’m talking about BDDfy by Test Stack. BDDfy, as you might infer from its name, is a BDD framework and one that bills itself as being dead simple both to use and to extend.
BBDfy is interesting in that it can run with any unit testing framework, but you can use it without even using such a framework. It’s truly flexible. And this extends to its philosophy with the flavors of BDD as well. You can employ its spec-flavored, context building functionality. But you can also then overlay it with so-called “stories” where you map the concept of agile user stories to units of code. This is how it becomes a behavior flavored BBD tool.
You’ll probably notice a theme here in that you install BDDfy with NuGet as well. You can also install a NuGet package that gives you usage examples as well.
ApprovalTests
Next up, let’s examine ApprovalTests (also on Github here). ApprovalTests falls more into the spec end of the spectrum as far as BDD tools flavors, but it has some novel elements to it.
The idea here is to model and test more involved bits of functionality than unit tests allow. In that sense, you have the same concept of NSpec and MSpec for constructing named scenarios with context. But with ApprovalTests, you introduce the concept of approvals. The name isn’t a non-sequitur by any stretch.
Here’s the idea: In code, you map your ideas in natural language and then turn those into test code, which you use to generate production code (in essence, making use of TDD). Then, your test suite captures the result of that production code in a file that describes the result in detail. And, finally, you approve the result when satisfied, which stores it for later. Changing an approved test means changing your requirements.
As you can probably guess, you can find ApprovalTests on NuGet, and it works with common test frameworks.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
SpecFlow
The last framework I’ll cover is the de facto incumbent in the .NET world. If you search around and ask around for BDD tools in C#, you will definitely hear about SpecFlow. SpecFlow falls firmly on the behave end of the spectrum of BDD tools.
Here’s how SpecFlow works. It follows given-when-then (GWT) syntax to map English statements to source code methods. The GWT statement reside in so-called feature files that are simply text files. The SpecFlow framework then uses source code configuration constructs to determine which code the statements should trigger. The end result… You have an automated system for running tests that non-technical people can easily read and discuss.
As with everything else, you can find SpecFlow on NuGet. But keep in mind that you’ll also want a Visual Studio plugin to help you run your SpecFlow scenarios.
Go Out and Experiment
So, which of these should you use? It’s hard to say. They’re all good tools, so I’d say go out try each of them for a bit, and see which one appeals to you. None of them has a particularly steep learning curve, particularly if you’re already familiar with automated testing.
In the end, it’s less important which specific tool you use and more important that you start having meaningful testing processes. BDD is a powerful tool for getting the business, testers and developers all in agreement on what it means for software to be done.
Written by Erik Dietrich, founder of DaedTech LLC, programmer, architect, IT management consultant, author, and technologist.
Cross-Technology | Cross-Device | Cross-Platform
