Gáspár Nagy on software

coach, trainer and bdd addict, creator of SpecFlow

BDD Addict Newsletter June 2016

by Gáspár on July 6, 2016

The monthly dose for BDD addicts… In June #bdd, #specflow and #cucumber stories from Gojko Adzic, Kent Beck, Håkan Forss, Michael Whelan & Gaspar Nagy.

Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the May issue?)


Dear BDD Addicts,

This is the 5th issue of the BDD Newsletter I started this year. It is still not a big number, but in the first six months I have managed to increase the number of subscribers by [division-by-zero]%. This is a big number, even very close to infinite. So thank you for the 123 subscribers and the many other readers browsing it online. (The past issues are available at bddaddict.com). Please keep sending links with a few comments to bddaddict@specsolutions.eu, so that I can share it with the other addicts.

Here is your monthly dose…

[Process] Extreme Programming 20 years later

We learned XP or TDD from Kent Beck or one of the works derived from him. So the next question should be: where did he learn it? In this video, he does not explain XP or TDD, but he decribes the driving forces that led him inventing these methods. Most of them are valuable to any of us as well, who would like to improve software development. XP started as a stupid idea… and if an idea is stupid, it’s definitely worth trying, as he says.

VIDEO: Twenty Years of Extreme Programming (Kent Beck, @KentBeck)

are-you-too-busy-to-improve2[Process] Too busy to improve

This post does not need too much explanation. We have all struggled with doing the same painful thing, just because we were stressed by the deadline or to deliver something. This is true for writing that test that would avoid the need of lunching the debugger and click through the application after each change. It is also true for setting up that build that automates the integration and deployment process. And it is also true for doing that small refactoring (cleanup) in the codebase that would make the long term maintenance much easier. So step back and you will see that our barrow is full of round wheels… Why are we struggling with square ones? The post of Håkan Forss shows some of these questions. (The illustration concept is based on the facilitation toolkits of Scott Simmerman, http://www.performancemanagementcompany.com/).

Are you too busy to improve? (Håkan Forss, @hakanforss)

[Process] Managing large set of scenarios

Creating the first few feature files is easy. But when the number of scenarios grows to several hundreds, the organization and structuring of scenarios and feature files become more difficult and complicated.

Gojko Adzic is here to help! He presents five recommendations for large test suites:

  1. Organise by function, not by sequence of implementation
  2. Cross-link for documentation, not for execution
  3. Reuse automation blocks, not specification blocks
  4. Document ‘Why’, specify ‘What’, automate ‘How’
  5. Optimise titles for discovery

Although these were written for large test suites, they make perfect sense for Cucumber or SpecFlow projects as well!

Five ways to reduce the cost of large test suites (Gojko Adzic, @gojkoadzic)

[Learn:UI Automation] Use your models

BDD can be viewed from many different angles. For me, BDD is a method that facilitates the discovery of the problem domain. The better understanding of the domain helps make a better model for the solution. A better model makes the solution simpler and serves as a guideline. So finally, you will see that specification (described with Gherkin), your classes, the database stored procedures and the CSS selectors you use for testing the user interface will stand together to a unified solution. Michael Whelan describes a very simple technique how the model classes of an MVC architecture (ASP.NET MVC in the concrete case) can be used for improving the web automation.

Using ASP.Net MVC View Models with Selenium WebDriver (Michael Whelan, @mjmwhelan)

[Learn:SpecFlow] Hook Order

SpecFlow hooks (or events) are extension points where you can insert custom automation logic into the scenario execution before or after different sections, for example before any scenario execution. In bigger projects, you might need to have multiple hooks of the same kind. These run in an arbitrary order by default, which can be problematic in some cases. Hook ordering is a new feature in SpecFlow v2 that can help you in this situation.

Put your hooks in order (Gaspar Nagy, @gasparnagy)

Spec Solutions

Comments are closed.