If you are new to BDD you may want to read BDD to the rescue first.
This is an introduction and a start of a series about bddify, a powerful BDD framework for .Net, called ‘Bddify In Action’:
- Introducing bddify: which is this post
- Using Method Name Conventions
- Writing stories
- Using Executable Attributes
- Using Fluent API
- Input parameters in Fluent API
- Mix and match them all
- Console report
- Html report
Customizing and extending bddify
- Customizing html report
- Creating your own report
- Create a step scanner
A bit of history
In January 2011 I started working with a team who did not have any exposure to BDD. The codebase they were working on could benefit from testing in general but more so from BDD; so I introduced them to the concept and they liked it; but the existing frameworks did not feel like a good fit for the team and organization. One of the reasons was that they were not doing Agile. The existing frameworks would work very nicely in Agile organizations but not as easily in non-Agile teams. Sure, BDD was born in Agile land; but in my experience it is as useful (if not more) for non-Agile teams. Also it always felt like an extension to TDD in the sense that in order to learn BDD you should first know and do TDD. This made BDD rather unreachable for average developers.
As such I started an attempt to make BDD very simple for every .Net developer regardless of their experience, knowledge of BDD and testing or whether they work on an Agile or non-Agile organization.
… and bddify was born as a one-file-framework. Well the first few incarnations were rather crude but soon it was turned into a fully-fledged BDD framework with quite a few handy and cool features. Since then bddify has been used by many teams in Australia and overseas: some developers learnt BDD through bddify and some switched to bddify after having used other BDD frameworks and luckily they are all very happy with it.
After one year, today I am pleased to announce the release of bddify V1. The code is now hosted on BitBucket and you can find it here.
What’s it called?
The framework is called bddify because it BDDfies (as in turns into BDD) your otherwise traditional unit tests. With bddify it is very simple to turn your AAA tests into a BDD test/behavior. Admittedly the ‘i’ in the middle makes it a bit confusing. At some point I was thinking about removing the ‘i’ and calling it ‘bddfy’ or ‘BDDfy’ but that would require a lot of work and many links would break and I would have lost a lot of history. So I decided to leave the ‘i’ there for now. What do you think?
Oh and BTW it is pronounced B D Defy.
Why another BDD framework?
Below are some of the bddify highlights:
- bddify can run with any testing framework. It does not force you to use any particular framework. Actually bddify does not force you to use a testing framework at all. You can just apply it on POCO classes even in a console app if that is what you need!
- bddify does not need a separate test runner. You can use your runner of choice. For example, if you like NUnit, then you may write your bddify tests using NUnit and run them using NUnit console or GUI runner, Resharper or TD.Net and regardless of the runner, you will get the same result. This means it integrates with the tools you know and love instead of adding yet another one on the top of them.
- bddify can run standalone scenarios. Although bddify supports stories, you do not necessarily have to have or make up a story to use bddify. This is useful for developers who work in non-Agile environments but would like to get some decent testing experience.
- You can use underscored or pascal or camel cased method names for your steps.
- You do not have to explain your scenarios or stories or steps in string: bddify infers them based on conventions but you can override the conventions if you need full control over what gets printed into console and HTML reports. Conventions galore in bddify and pretty much everything has a convention; but it is also very easy to override these conventions.
- bddify is very extensible. In fact, bddify core barely has any logic in it. It delegates all its responsibilities to its extensions.
- bddify learning curve is rather flat. Not only that but it makes learning BDD effortless.
Up until V0.9 bddify was a one-man framework – basically I was the only one working on it. I am not a big fan of one-man frameworks because they are a bit risky to use: if something happens to the sole developer of the framework or if he/she loses interest in maintaining it, the community will suffer.
Since early releases of bddify there was a programmer from London called Michael Whelan who provided a lot of feedback and comments on the framework. He also found and reported a few bugs. Recently he asked if he could help in the framework and soon he became a committer and in the short period he has been officially engaged with the framework he has provided a lot of help. So there are now two of us which is great. Hopefully the team of two will grow into a community of bddifiers.
bddify: the simplest BDD framework
This is only meant to be an intro and the actual technical content will follow in the upcoming posts; but I thought I’d give you a taste of bddify. So let’s give it a quick shot:
- Create a new test project in Visual Studio. It could be an MSTest project or a library project where your favorite testing framework is installed.
- Then install bddify nuget package: Install-Package bddify
- Now create a new class called BddifyRocks and paste the following bit of code in it:
AsA = "As a .net programmer",
IWant = "I want to use bddify",
SoThat = "So that BDD becomes easy and fun")]
public class BddifyRocks
public void ShouldBeAbleToBddifyMyTestsVeryEasily()
I am a big fan of NUnit and in all bddify demos I have used it; so I thought I’d use MSTest for a change here. Well, I admit this is not a real BDD behavior but I am just trying to show you the usage. You may now run the test.
Here is the what you get if you run using resharper:
The one line of code in the test method that calls bddify on the class instance turned my class into a BDD story and my methods into readable specification.
bddify does not care what testing framework or runner you use. Below is what we get if we run the same test using MSTest runner:
You will get decent result for TD.Net too:
What you saw above was console report generated by bddify as displayed by different test runners. bddify also generates html report(s):
An image does not really do a justice for the html report; so you may want to run the test yourself and play with the report.
Before V1 bddify generated the html report using RazorEngine. RazorEngine only works on .Net 4 which meant bddify could only generate html report for .Net 4 tests. This limitation has been removed because bddify no longer depends on RazorEngine. So if you are using bddify for your .Net 3.5 tests you can now take advantage of the html report.
This was just an intro
This was just a very quick intro to bddify and what you just saw was one of the many cool features of this framework. If you want to learn more about the framework stay tuned as I have got quite a few posts coming that will walk you through most of the features and explain how it works and how you may use it.
The code is available for download here and I have implemented the same test using NUnit too.
That is all for now.