The monthly dose for BDD addicts… In July #bdd, #specflow and #cucumber stories from Matt Wynne, Konstantin Kudryashov, Mathias Verraes, Liz Keogh, Roberto Lo Giacco, David Leitner & Gaspar Nagy.
Subscribe to the monthly newsletter at http://bddaddict.com so that you never miss it! (Did you get the June issue?)
Dear BDD Addicts,
Holiday season… many bdd addicts are away so they read and write less about bdd. Still, there is enough hunger that should be satisfied. So this month I am providing a selection of the most popular articles that have been shared in the BDD Addict Newsletter in the first half of 2016, based on the number of clicks, plus some weighting for earlier issues. Have you missed them? Did you subscribe only later? Now you can check what others were interested in the most.
Even if you are on holiday, please keep sending links with a few comments to bddaddict@specsolutions.eu, so that I can share it with the other addicts.
Let’s stop talking, here is your monthly dose…
[Process] Improve the collaboration part of BDD with example mapping
BDD bridges the communication gap by defining and using a ubiquitous language that makes a solid foundation for the implementation. This sounds good, but finding a good way for discussing and capturing requirements is not that easy. If you have ever participated in chaotic planning meetings or heated discussions about word ordering, then you know what I’m talking about.
There are ideas, like “three amigos”, but it means help only for the aspects of Who and Why, not for the aspect of How.
Matt Wynne, the co-author of the Cucumber Book, is really good at explaining processes and concepts. He has been always very sensitive to the problems people or teams may face. With his method called “Example Mapping”, he gives us guidance on how to facilitate planning meetings in a way that a valuable input can be produced for writing Gherkin scenarios.
Introducing Example Mapping (Matt Wynne, @mattwynne)
[Process] Climbing up and down inside the Test Pyramid
The test pyramid was introduced by Mike Cohn in the Succeeding with Agile book. The concept of the pyramid is pretty simple, but applying it for your own project is not easy at all. There are many articles explaining the different aspects of the pyramid. Konstantin Kudryashov (creator of Behat, the Cucumber variant for PHP) and Mathias Verraes wrote about how to move tests up and down among the levels of the test pyramid.
Economy of Tests (Konstantin Kudryashov, @everzet; Mathias Verraes, @mathiasverraes)
[Process] Given/When/Then — How to phrase them?
There is probably no single way how the Given/When/Then steps should be phrased and the rules are also language specific (Gherkin supports more than 60 natural languages). The best way is to sit together (as three amigos, maybe) and write a couple of scenarios together to find the phrasing style that everyone is comfortable with. When you are thinking about the right phrases, it is always good to consider what Given, When and Then steps are for. An older post by Liz Keogh can help you with that…
A Little Tense (Liz Keogh, @lunivore)
[Process] BDD does not have “test” in the name
The name Behavior Driven Development has been deliberately chosen in a way that the word “test” should not be in there. Not because we don’t like tests. Not because we don’t respect testing or testers. It is because BDD is primarily about specification, so we have to elevate tests to a level that they can be used for discussing requirements. Roberto Lo Giacco says it clearly: Cucumber is NOT a testing framework!
Cucumber is NOT a testing framework! (Roberto Lo Giacco, @rlogiacco)
[Learn:SpecFlow] How to structure test automation code with the driver pattern
Automating your first scenarios are easy. But with the ever growing, longer and longer step definitions you can very quickly get into an unmanageable mess. BDD sucks.
Well… regarding my experience, the problem is in these cases that the authors don’t apply the same code quality rules for the automation code as they do for production code. They simply implement the “Scenario -> Step Definition -> Application” chain literally and build a flat automation layer with a lot of code duplications and strong coupling.
Good design patterns can help, like the driver pattern that is a generalization of the window driver pattern (aka page object pattern). At the end of the day, it is not much more than layering your automation logic and separate the concerns, but it plays well with the SpecFlow context injection feature, as summarized by David Leitner in the following article.
Driver Pattern empowers your SpecFlow step definitions (David Leitner, @duffleit)
[Learn:SpecFlow] All those tricky base classes
It is not a recent post, but I am still receiving a lot of views on my post that is about using base classes for step definitions, so this still seems to be a topic that can never get boring.
The situation is clear. You want to split big step definition classes into smaller ones, but still being able to pass state across the step definitions now in different classes. Base classes sound like a valid option, but they are not. The article explains why…
SpecFlow tips: Problems with placing step definitions to base classes (Gaspar Nagy, @gasparnagy)
