Category Archives: Uncategorized

BDD with SpecFlow @ SkillsMatter

Gaspar and Jonas did two workshops about BDD with SpecFlow at Skillsmatter in London.

In the first workshop they introduced the concept of BDD, and demonstrated the development workflow for building a system based on Gherkin acceptance criteria.

Jonas explained the key concept of “specification by example” and how it can be formalized using Gherkin to build the ubiquitous language amongst all stakeholders in a project. That’s why SpecFlow and Gherkin are actually aiming at specifying the details of a system. Testing of the completed system for compliance is just a by-product. Having the detail specification bound to the actual implementation ensures, however, that it is kept up-to-date throughout the whole application life cycle. It makes detail specifications valuable even after finishing the implementation of a given feature, as they are a business readable description of how a system truly behaves.

After the theoretic introduction, Gaspar did a coding demo, binding and implementing the first Gherkin formulated acceptance criteria of their sample domain. He used the SpecFlow book shop sample (using an MVC2 architecture), where he automated the first Gherkin scenario through the controller. From there, he implemented the necessary logic using TDD, until the scenario turned green. After that, there was an exercise for the audience to bind and then implement the next acceptance criteria for the application.

The second workshop focused on the process of how to harvest useful acceptance criteria and the challenges involved with that.

After a short introduction, the audience got the task to formulate acceptance criteria (scenarios) in Gherkin for a given user story (feature) – using pencil and paper. The groups presented their results and there was a discussion about the challenges people encountered and anti-patterns we found in the results. This exercise made it obvious to everyone,  that the key concept to master in BDD is not the tool (e.g. SpecFlow), but understanding the process of distilling and formalizing acceptance criteria in Gherkin.

I particularly liked this part of the workshop, as it not only was an exercise for the individual participants, but also a good demonstration for the challenges in BDD. Even if you are just watching the podcast, the discussion of the results and challenges everyone found is helping a lot to get a better understanding on detail specifications in Gherkin. Also Gaspar’s comment on the technical “TDD perspective” of a developer vs. the “business perspective” on acceptance criteria provides lots of insight.

The second workshop concluded with a summary of challenges and anti-patterns we encountered so far in our experience, and a discussion about how testing fits into BDD. In our projects we mostly automate below the UI, as this is much cheaper to achieve and maintain. It also ensures, that we really can automate all specified acceptance criteria. The main goal of using SpecFlow is not automating through the UI, but having an automated verifiable detail specification. Even if you automate through the UI, it doesn’t spare you additional efforts such as explorative testing.

If you are interested in using SpecFlow, I strongly recommend you watching those two workshops. Skillsmatter has put both of them online as a video podcast:

(Note: podcasts will become available in the next few days)

You can also download the hands-on material for Day1 and Day2 to try out the exercises on your own.

If you are interested in getting deeper into SpecFlow and need a head start, we can provide similar workshops on-site in the domain of your own project. Contact us at info_at_specflow_dot_org.

Advertisements

Why start a blog now?

Well, I do have to admit that I am part of the late majority when it comes to blogging. So why am I bothering to start a blog now?

I am a managing partner at TechTalk – we are about 50 people, doing consulting for software engineering in enterprise application development, with a technological focus on the Microsoft .NET platform. Besides general management tasks, my primary role is to lead the advancement of our technical and methodical expertise in software engineering. I share management responsibility with my two other partners, who focus on leading our sales/marketing efforts and our project operations.

Being a technical leader was easy when we started. I joined TechTalk in 1997, and although the team grew quite quickly in the first years, projects were pretty much a hands-on experience for me. Communication was also easy, up to the point where we hit the 15 people mark. Since then, my role gradually transformed from daily coding to being regularly involved with architecture (I wouldn’t call myself an architect, though) and whose daily practice is rather about facilitating teams so they can successfully build enterprise software systems.

While I am happy with the transformation of my daily work, the lack of communication within the growing team increasingly started to bother me. In the early days, I knew about every project detail and all the problems and solutions we found, but now there are some projects which I only learn about in more detail when there are already problems to deal with. Even worse, I also have the impression that we have to overcome great resistance in order to transmit findings and perceptions from individual projects to other teams, let alone spread them generally in the whole company.

Another interesting aspect is that my opinions and standpoints are constantly evolving through the experience I gain in my daily work, and inputs I get from external peers. What I found useful a year ago might be not the same approach I would take to solve the same problem today. My colleagues are sometimes surprised when I disagree with positions I took fiercely not long ago. But I think it is essential for a successful team or company to constantly strive for improvement, learning new things, and embrace the resulting change; and that it is one of my primary objectives – to facilitate this process at our company.

Out of these aspects, I decided to start a blog with the following motivations:

1. Document problems, discussions and findings from our daily work, to have them spread more easily within our teams and organisation.

2. Provide a log of my opinions and standpoints, to make it easier for myself, my colleagues and peers to track how they evolve.

The primary target audience of my blog is our own organisation and maybe also some of my peers at our customers. In the intermediate term, I also hope to draw the attention of external readers on some topics I write about, to gain additional outside viewpoints on them.