BDD Addict Newsletter October 2019

Gáspár Nagy
6 min readNov 11, 2019

Which BDD practices are useful? — The monthly dose for BDD addicts

In October stories by Kent Beck, Luke Morton, Gaspar Nagy, Tim Ottinger and Matt Wynne…

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

Dear BDD Addicts,

This October was a busy month. Conferences, courses, on-site coaching. But whenever I was thinking about how I should introduce this newsletter, I always ended up thinking about Skills Matter.

Last week I was in London at the P3X conference at Skills Matter. Friday was the last day of the conference, and it turned out that possibly it was the last day of Skills Matter as well. Skills Matter has gone in administration (appointed administrators trying to sell the business or closing it if that fails). P3X is my “home conference” if there exists such a term at all. It has been organized since 2009 (it was called BDDX before 2017) and I have attended many of them and have been part of the program committee for a couple of years now. This was the conference where I’ve done the majority of my knowledge exchange around BDD in the last 10 years and here I’ve met a lot of people who have been influencing my activity. Skills Matter has been playing a key role in establishing a community committed to build quality software and their company has also served as a role model for other local communities and meetups all around Europe and beyond. So please let me dedicate this issue of the BDD Addict Newsletter for everyone who worked and contributed to Skills Matter.

This is not the end.

So let’s keep working.

Photo by Alvin Engler on Unsplash.com

[Agile] Fail, learn and move on

On the occasion of the 50th anniversary of the Moon landing, I have been reading about the Apollo 11 project and have found a couple of interesting details that might carry a message for agile software development as well. One of these small details was that before the launch the crew (Aldrin, Armstrong and Collins) were told that if they failed to land on the Moon they could lead the next mission as well. (Normally the assignment of the people to the missions was rotation-based.) With this, NASA wanted to avoid that the crew took unnecessary risk during the project. There is always a new chance, so we should better fail and learn from the failures. This is what Tim Ottinger’s thoughts are about.

This is NOT the End (Tim Ottinger, @tottinge)

Photo by History in HD on Unsplash.com

[BDD] What BDD practices are useful?

Agile is about inspecting and adapting and this is also true for the agile practices, like BDD as well. Something that I have found useful, might not be relevant for you, but another thing that I was not focusing on might have more impact. This is why I like attending conferences and exchange BDD experience. And also this is where questionnaires and statistics are also helpful. They show how people adopt things. Matt Wynne and the SmartBear team have recently made a quick survey. Matt has summarized the results in the following post.

What do high-performing BDD teams do? (Matt Wynne, @mattwynne)

Figure from Matt Wynne’s blog post

BDD with SpecFlow course

for developers and testers
with Gáspár Nagy

EARLY BIRD TICKETS ARE STILL AVAILABLE FOR BDD ADDICT SUBSCRIBERS!
Drop us an email and refer to the October issue of the newsletter!

[BDD] Drive your requirement workshop

There is one thing in common in all the companies I visit nowadays. They have all realized that they could improve their development process further only if they reduce the waste (time, code, etc.) caused by the suboptimal communication of requirements. I show them example mapping (and other deliberate discovery practices), we also practice it, and it becomes quickly visible that these practices can really help. However, collaboration, which is the essential part of them, does not come automatically unfortunately. Unfacilitated meetings quickly turn into an “Is it clear? — Yes” kind of discussions. Becoming a facilitator of such meetings needs a bit of practice but it is not super hard. I have tried to collect the most important facilitation techniques I use.

Example Mapping: the good enough facilitator (Gaspar Nagy, @gasparnagy)

Photo by You X Ventures on Unsplash.com

[TDD] Properties of automated tests to consider

I have labeled this post with “TDD” but it is more about test automation in general. I have seen that people like categorizing and establishing rules too rigidly, while the test automation landscape is much more diverse. There are different contexts and we need to find our way there. I prefer the concept of listing principles or properties that can or should be considered. You are not obliged to keep them, but you should have a good reason not to do so. Kent Beck has made up a quick list of such properties with a few examples on how to use them.

Test Desiderata (Kent Beck, @KentBeck)

Photo from Kent Beck’s blog post

Testing is important. This is a conference about getting experts and practitioners together to talk, learn and practice the art of testing.

European Testing Conference

6–7 February 2020, Amsterdam (NL)

Come. Learn. Do. Teach. Test.

[Test Automation] Clean, but not so dry

A proper implementation of the agile principles on a project requires us to think differently about testing and test automation code. Quality (and all related testing and coding activities) are the responsibility of the whole team. The results should be treated as important and valuable artifacts. “Tests should be treated as first-class citizens” is a commonly expressed attitude, and it follows that test automation code should adhere to local coding standards, such as the “Clean code” principles. There are discussions about how these principles can and should be applied to test code, especially on the “Don’t repeat yourself” (DRY) principle. While the DRY principle for production code is important to avoid duplication and redundancy, for test code, keeping the structure simple and readable (sometimes mentioned as DAMP — Descriptive And Meaningful Phrases) seems to be more important than the DRY principle. Luke Morton shows a couple of concrete examples for this problem.

When to avoid the DRY principle (Luke Morton, @LukeMorton)

You can learn and practice this and other tips about SpecFlow on my SpecFlow course (official SpecFlow course). See the upcoming courses or book a private in-house course!

My SpecFlow, BDD Vitals, Cucumber, Robot Framework, XP Today and TDD Today courses are also available as private training. Contact for details.

If you liked this newsletter, please consider giving a 👏 or two and follow me for future stories. Thanks for reading.

Gaspar Nagy is the creator of SpecFlow, developer of SpecSync, working as a trainer & coach. Check out his public SpecFlow, BDD Vitals orCucumber.jscourses or request an in-house private course for your team. He is a bdd addict and as such he’s editing a monthly newsletter about interesting articles, videos and news related to BDD, SpecFlow and Cucumber.

Originally published at http://gasparnagy.com on November 11, 2019.

--

--