TL;DR

The best way to hammer the open session conference is with the keynote session. The second keynote session was from Gaspar Nagy, Give A Boost To Your Agile Project With BDD.

Gaspar is the author of the open-source tool,  SpecFlow. Ruby’s counterpart is Cucumber gem. SpecFlow enables you to write feature files in Gerkin Given/When/Language, implement steps in C#, run those specifications, and present results in meaningful reports. BDD stands for behavior-driven development. I like this because it does not mention testing. This tool is a development tool that enhances team communication by providing running examples to get the information is something done or not. Gaspar is also the author of two books, Discovery and Formulation that help you to master effective BDD.

Gaspar starts with anomalies in an agile testing project that we all experienced. We start with a sprint where user stories are implemented. By the end of a sprint, testing begins. The tester found bugs, or just have some questions for developers. But developers are already working on new user stories and do not have time to resolve bugs or answer a lot of questions in this sprint. So implemented user stories flow to the next sprint and become the project debt.

Then the team starts with automation. New problems arise. Tests become big, and that leads to:

Small test, small problem. The big test, big problem.

All automation for code checks happens in the UI part of the application. Those tests are slow and brittle. The next question is

Where do bugs come from?

Gaspar lists some of them: coding errors, miscommunication in requirements; humans are error machines. We have two approaches to testing:

• bug hunting
• bug prevention

Bug prevention is the famous “Shift left” paradigma. Check automation falls to bug prevention of known bugs.

So what is behavior-driven development BDD? It is specification by example. Every requirement (let’s say user story), should be accompanied by several examples that represent possible flows of that story. And for that, we have BDD feature files written in Gherkin.

Gaspar asked, What is functional quality? The function must work. But he adds additional parameters: expectations are reasonable and documented.

In the demo, he presented on Geek Pizza example how to get from BDD files to working selenium tests in SpecFlow.

In conclusion, when the project starts, requirements are in high flux. In that phase, it is essential to have quick information about requirements implementation. SpecFlows helps in solving that problem.

My Aha moment is that BDD is not for writing complex scenarios where we test several functions (features) altogether. We should divide scenarios in atomic features and cover those features with specification by example.