Gáspár Nagy on software

coach, trainer and bdd addict, creator of SpecFlow; owner of Spec Solutions

BDD Addict Newsletter March 2021 (#53)

by Gáspár on March 10, 2021

Dear BDD Addicts,

Spring is here and it seems to be the time of anniversaries. There has gone a year since COVID broke out as a pandemic in Europe, the first BDD Addict newsletter came out 5 years ago and many people are talking about the 20 years anniversary of the Agile Manifesto.

I have heard a couple of stories from the manifesto signers, but it is still hard to imagine the discussions and the motivation that made them compose the manifesto. Although it was definitely an important moment, it was really just the beginning. The work is still going on.

So, here comes the monthly dose for you, dear fellow BDD addicts.

Picture by GRStocks on Unsplash.com

[Agile Testing] Why do we insist on separating testing from coding?

Probably you have read many articles focusing on the “test first” approach. You might even practice it on a daily basis. But when working in a larger team, especially when the team is in release-stress, we get back to those debates, whether we should do test first. You might have your own answers and arguments for this, but read what Janet Gregory says: is it possible that even the question is wrong?

Testing And Coding, Not Coding “Then” Testing (Janet Gregory, @janetgregoryca)

Picture from Janet Gregory’s post

[Gherkin] Data in the scenarios

Probably the “essential data” principle from the BRIEF principles of good Gherkin is the hardest to practice. We hesitate between making the scenario super precise and detailed or making it more abstract but better maintainable. And it turns out that those super-detailed scenarios cause serious maintainability problems and make BDD unscalable. But how can we focus on essential details if those details are represented as hierarchical data? Gojko Adzic has gathered some answers through the latest #GivenWhenThenWithStyle challenge.

Solving: How to specify hierarchical data? #GivenWhenThenWithStyle (Gojko Adzic, @gojkoadzic)

Picture from Gojko Adzic’s post


[BDD] How using examples for specification can improve the development process?

I have been using Example Mapping for many years now and always wonder why it isn’t used for more projects. I have seen many times how the magical question “Could you please give an example for this?” can improve the shared understanding of the problems we need to solve. So I was really happy to read the post by Corrado Calzoni about their experience.

How Example Mapping Improved My Team’s Development Process (Corrado Calzoni, @corrado_calzoni)

Picture from Corrado Calzoni’s post

[BDD] BDD vs TDD through examples

I shared an article about the “BDD vs TDD” topic in the previous issue, but this topic seems to be important and relevant as this was the subject of one of the #GivenWhenThenWithStyle challenges (Dave Farley responded with a nice video to it) and Ken Pugh has also summarized his thoughts. Ken uses a simple example to show the goal of BDD and how it relates to the different kinds of tests.

Behavior Driven Development – From End-User to Unit Tests (Ken Pugh, @kpugh)

Picture from Ken Pugh’s post


[Tools] Living documentation to support teamwork

Fortunately there are more and more tools that can help integrating BDD into our development process. Probably the hottest topic is about reporting and living documentation. This should not be a surprise, because once a team has built up the feature structure, formulated and automated scenarios, they would like to get the most benefit out of it. The SpecFlow team at Tricentis has recently invested a lot of energy into making living documentation reports better usable with the help of their free tool, called SpecFlow+ LivingDoc. Andy Knight shows in his post how they use the tool and how the generated living documentation can help the teamwork and communication with the customer.

Improving Teamwork with SpecFlow+ LivingDoc (Andy Knight, @AutomationPanda)

Picture from Andy Knight’s post

Comments are closed.