.NET – Companies Using BDD in a .NET Environment

First off, let me add a little clarity. BDD is not exactly TDD. A lot of people confuse the two because they both start with the concept that you write tests before you code. BDD has been described as "better TDD" or "doing TDD right", but I'm not sure that really applies either. Personally, I consider BDD as a Refocused TDD.

The idea is that you are able to do a number of things that many other approaches sometimes struggle with, and these are some of the advantages that you are probably looking for:

1. Your test code captures all of your requirements in a human readable form. I'm not just talking about method names and cleverly factored code, but instead the use of a good BDD framework allows you to write your tests using the language of the feature or story text you would have written down in a requirements document. (Look at something like StoryQ for dotNet as an example).
2. Your test code actually ends up testing to your requirements. If you write your test in the language of your feature specification, your end up testing to the specifications directly.
3. Test output reads like a report. Most unit testing scenarios result in a bunch of lights or onscreen flags to indicate pass or failure, but you get very little idea where the actual error has occurred beyond the approximate place that it was triggered. BDD output provides you with failure information regardless of whether the failure occurred in the execution of the code, or in the setup parts of your test, which leads me to the next point...
4. Your test code becomes highly granular, allowing you to more easily pinpoint the nature of failures in your tests/code.
5. Continuous live feedback through your tests means that you tend to work a little more efficiently, especially if you are applying a Test Driven process rigorously. Personally, I write all of my tests before I start to write any code. IT's a kind of up-front design without getting too tied to anything specific, and easily refactored if I change my mind later on.

For what it's worth, I use BDD regardless of whether it's at my job, or on my own side projects at home. I'm slowly converting others in my workplace to this approach, because I am able to show the advantages in terms of my productivity, and the lovely side-effect of having cleaner and more readable tests, and by extension cleaner and more readable code - although that last bit is not implied as a BDD benefit, but just to show you that I personally found myself leaning more in that direction.

Cheers.

In general userstories are requirements from the customer point of view that most of the time say what to implement (= features) but not how to do it (design, workflow).

If you want to create a new app out of nothing (greenfield-soulution) in a agile/scrum-like manner out of existing userstories i would suggest this workflow:

• bring the userstories into an implementition order to find out which story to implement first. Start with stories that have as least dependencies to other stories as possible and that have most business-value. For details see StoryMaps-The new user story backlog is a map
• implement the first userstory as nesteted bdd/tdd loops