The monthly dose for BDD addicts…  At the end of 2018, stories by Aaron Cohen, Ed Conolly, the Cucumber team, Erick Dimistracopulos, Dave Farley & Michael Stephenson   …

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

Dear BDD Addicts,

We are getting close to the holiday season and the end of the year. It has been a busy period for me and a busy year altogether. We finally started to progress with the Formulation book with Seb Rose and I hope I will be able to share with you soon what BRIEF means in the context of writing BDD scenarios. I also had to prepare for an XP (eXtreme Programming) course.  Maybe because of this course you will find a bit more dev topic in this newsletter, but I hope you don’t mind.

Have you seen any other that would fit? Please send me the link to bddaddict@specsolutions.eu.

Let’s see the last dose in 2018 and I wish you a merry Christmas and happy holidays…

---

[BDD] BDD Under Pressure

The Cucumber team has a long history of teaching good BDD habits by showing the mistakes that teams usually do. (Do you remember the “Cucumber anti-patterns” articles?) This time they are focusing on team and project issues that make the successful adoption of BDD harder or even impossible. There are 10 points listed as it should be in a “10 things…” article, but my favorite is the pressure. I know it from teaching… an exam at the end of the course makes the learning process less efficient, because they will focus on — what a surprise — passing the exam, instead of learning new things that they might be able to use. Keep up the sustainable pace and read the tips for BDD adoption from the Cucumber team.

10 easy ways to fail at BDD (Cucumber team, @cucumberbdd)

---

[DEV] Pair programming: SOS we are introverts

I have delivered an XP training recently, where we have also talking about and practiced pair programming. The concept of pair programming is simple (but not necessarily easy), but the hardest thing is to imagine it to work as the primary way of coding. This is probably due to a few misconceptions or misunderstandings. One of the key question is how you can constantly do full working days while constantly communicating and intensively working with someone else. The answer is that you can’t. Everyone needs some private time even at the workplace and there is nothing wrong about this. You should not feel guilty or incapable. Dave Farley is an authentic source to listen to. Not only because of his background for Continuous Delivery, but also because he is an introvert himself. So let’s listen to what he is saying.

Pair Programming for Introverts (Dave Farley, @davefarley77)

---

---

[DEV] Your branching, your strategy

The GitFlow branching strategy has been published in 2010, so nine years ago. Even after nine years, it is a nice article in my opinion. But as it usually happens, people have taken and applied it to their own context (which is probably totally different from the author’s one) blindly. And it did not work or at least not as good as they expected. GitFlow is wrong — that was the verdict and people started copying someone else’s model. And the same story starts again. If you want to get out of this circle, read the original GitFlow article again, but now try to focus on how to explain, document and visualize a branching strategy. Sit down with your team, analyse your own situation and make your own strategy (and be ready to change it later). The post by Ed Conolly is a bit of help to this as it analyses a few usual problematic situations and lists some alternatives.

Some thoughts on branching strategies (Ed Conolly, @ConollyEd)

---

[BDD] BDD for DevOps

DevOps is to get development and operations closer together and there are many elements of this, e.g. better use of information we get from monitoring or scripting all deployment and configuration details (infrastructure as code). But to get a shared ownership of those scripts and infrastructure code the team has to have a better understanding of the environment our systems are operating on and also a better documentation of what we are doing and why. Although BDD is primarily for working with functional business requirements, it could be also used for defining our expectation for the infrastructure. In his article, Aaron Cohen gives a few hints and starting points for this. Interesting! (The article loads slow, be patient.)

A Behavior Driven Developer’s guide to Infrastructure as Code(Aaron Cohen)

---

---

[Agile Testing] Is Agile Testing only for hobby projects?

I had an embarrassing chat at one of the agile conferences with a person who worked for a big enterprise. He tried to convince me that agile would never be used in his company, because what they were doing is far too important and too serious for agile. Even if he would let me say a word, I could not really even say anything to that. I was shocked. I know that agile transformation is never easy, especially for larger organizations where cultural changes (and changes at all) are difficult. But I have never heard the argument that the problem with agile is that it cannot be used in businesses where defects are costly. I think it is rather the opposite. When I stumbled across the article by Erick Dimistracopulos, I immediately knew that he might have had a similar affair. Thank you for the demystification, Erick!

https://www.linkedin.com/pulse/demystifying-agile-testing-erick-dimistracopulos/ (Erick Dimistracopulos, @edimistra)

---

[SpecFlow] BDD for Azure Functions

Serverless architecture is a hot topic nowadays (despite the bad name). Azure Functions is Microsoft’s implementation of the concept. But how can you verify the behavior of an Azure Function with SpecFlow? Michael Stephenson gives a warm start for that.

Azure Functions and SpecFlow (Michael Stephenson, @michael_stephen)

---

Upcoming SpecFlow, BDD Vitals and Cucumber courses