by Jonas Bandi and Gaspar Nagy, published in NDC Magazine, 2011 (download the magazine in pdf here, 13Mb!)

SpecFlow is a prospering open-source project for .NET / Mono that was founded one and a half a years ago, and has attracted quite a lot of attention in the .NET community since. In this short self-interview, we talk about SpecFlow’s birth and the challenges we faced providing it as an open-source project.

Jonas: “I think Cucumber offers a lot of potential for Agile development.” This sentence started the SpecFlow story for me.

Christian Hassa, one of the managing partners at TechTalk said this to me one evening in Spring 2009 in a hotel lobby in Zürich. This was after my first job interview with TechTalk in their new office in Switzerland. After the interview, we kept on talking about our ideas and visions of Agile development and software testing.

At the time, I was not familiar with Cucumber. I had seen demonstrations of RSpec Story Runner before, but this was like black magic to me at this point.

Gaspar: Cucumber was our third attempt to do specification-based functional testing and BDD. We were already beyond using annotated Selenium tables and building a proprietary language. Cucumber was helping us really concentrate on the specifications, while still being able to automate the application easily.

Jonas: After the interview I went home and eagerly began exploring Cucumber on the web. What I found was very interesting…

Fast forward five months. I decided to join TechTalk. My first real contact with the company was a company event in Sopron, Hungary. I arrived late at the hotel. Everybody was already well fed by a gigantic barbecue, and beers and drinks were circulating.

My SpecFlow story continued, again in a hotel lobby:

Attila, a developer whose mighty appearance honors his name, was kneeling in front of a salon table where he had placed his laptop and his beer. He was arguing fervently with a group of TechTalkers about using Cucumber for .NET development. He was typing fast in Vim and showing the output of his Ruby code in the console.

Most of the spectators standing around kneeling Attila were not really in the mood for discussing deep technical stuff, as they were much more interested in their drinks. But Gaspar was arguing deeply with Attila.

The main arguments concerned the accidental complexity and slow execution time that is added by using Cucumber under IronRuby for common .NET development.

I was fascinated by the depth of the argumentation between Gaspar, Attila and the other TechTalkers. Of course the discussions went on until deep into the night.

Gaspar: And not only the discussion… I had a technical concept ready by the end of the event.

Jonas: I returned to Switzerland. A week passed. Then Gaspar came forward with a first implementation of a tool that took Cucumber features and turned them into natively executable .NET code. Already integrated into Visual Studio!

SpecFlow was born… only we did not know the name of this new baby yet.

Since then I have learned that this is Gaspar’s very pragmatic way:

If he doesn’t like something, he doesn’t argue too much about it; but he works up a better solution.

Gaspar: Actually we had two choices: either we fail with BDD in this project because of the issues or I put together something very quickly (maybe I’m really pragmatic…). An interesting detail is that the very first version had its own parser, using the Oslo M grammar. And now we are in Oslo presenting SpecFlow – what a coincidence.

Jonas: For a month or two we tested the new tool on our own projects.

We were improving it and of course we were arguing…

Soon we decided that our new baby was ready to be shown to the world.

We thought we wanted to name it NCucumber, going with the naming fashion for .NET clones of projects from other platforms.

We contacted Aslak, the father of Cucumber, but he did not permit us to use the name for something that was not really grown from the real Cucumber seed.

At the time, there were several .NET Cucumber clones sprouting up, and Aslak was not fond of the idea of them using Cucumber’s well-earned name .

Proud creators ourselves, we went on searching for an appropriate name for our beautiful baby.

We did not want the word “test” in it, because the BDD workflow is not about testing but about building a shared understanding.

Candidates were “ZinC – Zucchini is not Cucumber”, “ScenarioSpec”, “SpecNarrator” and “SpecFlow”.

Finally the word Spec and the smooth motion of flowing (compared to the abrupt waterfall) seemed to fit our ideas perfectly… and the specflow.org domain was still available.

Finally we presented SpecFlow to the world: on October 22nd 2009 we committed SpecFlow on GitHub.

Gaspar: This was my first OSS project and it was a very strange feeling to put the source code online: being naked; putting up the pages of your diary on the wall – somehow like this. I did not know what would happen; how the contributors would join, whether anyone would abuse our achievements. It took me some time to get used to this, but I’m fine now.

Jonas: It seemed that we hit a nerve: very quickly we got quite a lot of attention. Only a few days after our first release, we got several interested users who contacted us with the intention of helping us grow the project.

However we found ourselves trapped between several other fresh open-source .NET BDD tools and the already major Cucumber project itself. How should we proceed? Where should we look for alliances? Who were our competitors?

Gaspar: Especially interesting in this regard is the evolution of the Gherkin parser in SpecFlow. Gherkin is the plain-text language (“Given-When-Then”) that Cucumber defined for writing specifications. SpecFlow had its own infrastructure for parsing the files (first with M Grammar and then with ANTLR), but remaining compatible with the “official” Cucumber Gherkin was hard. Other tools in the Cucumber-family had similar issues, and Aslak realized that there is a lot of value in the specification language itself (even without the Cucumber runner), so he gave a name for it (Gherkin) and extracted it from the core Cucumber project. The new “official” Gherkin parser supports several languages and provides a solid foundation for Cucumber-related tools. An interesting detail is that the Gherkin parser supports .NET through an OSS Java/.NET bridge called IKVM.

We jumped on this opportunity and retired our own parser.

Jonas: We realized that long-term commitment was the key to success for an open source project. Cucumber demonstrated this commitment and we could build on that if we stayed close to Cucumber. We tried not to compete with other .NET BDD tools, and just concentrated on our own goals.

Another important aspect was community building. In the beginning we did not know where SpecFlow was heading: we had no experience in leading an open source project and we were not even familiar with the BDD community.

We were quickly able to establish good relations with some of the proponents of the Agile testing community in London, where most of the BDD mindset was coming from.

Getting familiar with ideas and concepts like BDD, ATDD, specification by example and outside-in development was crucial for us to give the project a real vision.

The focus on the theoretical foundations on which SpecFlow is built is visible in the SpecFlow Google Group, where discussions about BDD concepts and best practices outnumber the purely technical questions about SpecFlow.

Gaspar:  I’m always amazed by the level of discussions on the forum. When we started SpecFlow, I was afraid that all my time would be taken up answering support questions. Instead, it is rather a joy to read the forum posts, and most of the pure support questions are answered by somebody before I even see them.

Jonas: A positive side effect of our focus on the methodology was that we got more attention from the community. We were not perceived as “yet another tool” but as a serious proponent of the BDD mindset.

Consequently we got mentioned several times on prominent sites like InfoQ and MSDN and we started to get invited to conferences…

Gaspar:  I cannot count the workshops, meetups and presentations where we have shown SpecFlow anymore. But it is clear that NDC is an important milestone in SpecFlow’s short life and it is a great honor to be here.

Gaspar and Jonas want to thank all the SpecFlow contributors. Special thanks go to Xerxes Battiwalla, Dale Ragan, Darren Cauthon and Marcus Hammarberg for their continuous effort. SpecFlow is sponsored and supported by TechTalk.

 

SpecFlow can be found at www.specflow.org and at http://github.com/techtalk/SpecFlow/

Gaspar and Jonas work for TechTalk (www.techtalk.at). They are the maintainers of the SpecFlow project.

You can find their thoughts online on their blogs at https://gasparnagy.com/ and http://blog.jonasbandi.net/

And on Twitter at http://twitter.com/gasparnagy and at http://twitter.com/jbandi