Dear BDD Addicts,
I would like to use this occasion to wish you a happy new year for 2022! I hope you are fine and you have probably noticed that there has been a bigger gap in the BDD Addict newsletters. It was a busy year and once you have got out of your rhythm it is harder to get back to it. But now I am here again with interesting blog posts, articles or session recordings related to BDD, Cucumber, SpecFlow, agile testing or test automation in general. If you have also seen a good one, please let me know at bddaddict@specsolutions.eu, so that I can share with others.
I don’t know if this year will be as busy as 2021 was, but I have a handful of ideas that I would like to make real this year. Probably the most important is to continue with the BDD Books series. The next book is going to be about BDD automation patterns. I wanted to create such a book for many years, but now it can be done with your help. With Seb, we have made a call for contribution that you will see below. I am very excited to hear about your ideas!
But now, let’s see the posts for today!
[BDD] Case Study: Improving confidence with BDD
I keep being asked for stories about companies who successfully implemented BDD. There are not too many written case studies in the internet, although I know about many teams enjoying the benefits of BDD. Probably some teams hold back their stories because of confidential details, but I think the real problem is the question itself. Implementing BDD successfully — first of all, we need a definition what successful means. Agile is about inspect and adapt – a continuous improvement, so the definition of success is difficult. The other problem with the question is that it sounds like implementing BDD would be the ultimate goal. No, it isn’t. BDD is a practice offering you help to your own problems.
I hope that many of you will be inspired to write about your own story by reading the case study by Andy Knight. They have introduced BDD for very specific reasons and combined the existing tools and knowledge with a bit of innovation. In the end they got to some useful result.
How Q2 uses BDD with SpecFlow for testing PrecisionLender (Andy Knight, @AutomationPanda)
[BDD] Automation vs readability and other common BDD-related questions
In presentations and conference talks, I like the Q&A part the best. Both as a listener and as a presenter. A good question is already half-way to find the solution.
Seb Rose did a presentation on the Automation Guild conference, but some of the questions in the Q&A remained unanswered. Seb answered them in a blog post series that I really enjoyed. I have linked the one that is related to one of my favorite questions, but I encourage you to read all the answers (see links in the post), because those also address interesting questions.
What’s wrong with changing the scenarios to enable automation? (Seb Rose, @sebrose)
[Agile Testing] Don’t automate test cases!
I generally have some sort of reservation against the “X things” kind of articles but the one by Blake Norrish is really worth reading. It provides a good summary of the most important agile testing principles, but in an inverse way. The one that has caught my eyes said that automating test cases would mean that you are not “that” agile. What? What’s wrong with automating test cases? These were my initial thoughts. But just think about it for a moment… and read what Blake said about it…
Eight Signs Your Agile Testing Isn’t That Agile (Blake Norrish, @blakenorrish)
[Agile] The things that everyone knows, as we think
One of my “favorite” concept in BDD is the phenomenon of “unknown unknown”, when we get into a misunderstanding because we don’t know that we don’t know something. This typically happens when we have an assumed answer for the question and we don’t realize that it is not necessarily what the other party assumed. It’s about implicit knowledge.
In her post, Janet Gregory shows how we could realize and avoid too much reliance on implicit knowledge of the team members.
Implicit/Tacit Vs Explicit Knowledge (Janet Gregory, @janetgregoryca)
[SpecFlow] SpecFlow for cross-platform teams
The .NET framework made a long journey to become cross-platform, but as more and more teams develop .NET applications on non-Windows devices, the development tools, particularly the development environment (IDE) need to be adapted to cross-platform too. Visual Studio Code is a great starting point for that.
Although SpecFlow does not have any official extension for VS Code, with the existing extensions and a little bit of tweaking of their settings you can setup a convenient working environment. Raj Uppadhyay provided a detailed guide about how this can be achieved.