BDD story anti patterns
I recently took some timout out of reading the many BDD blogs and resources to reflect on my current state of BDD. How I look to enhance communication and how I record this communication so that it still reflects the same intent as when it was first disocvered. Just looking at previous feature files I have created I came to see what I consider BDD Anti Patterns. They are a common theme of “mistakes” that I have been making over X years.
In this article I will look at each anti pattern and explore the reason I feel it should be changed and how it can be expressed differently.
Setting the wrong scene
This was the first “Anti Pattern” I found form looking at my conversations. I found many references in my work to scenarios that looked very similar to the following:
Now my problem with this scenario is around the use of “Visitor” I know from talking to the product owner that we have different types of visitor yet in all my scenarios I just refer to them as a visitor and use
Given I am now logged in to alter the state of the user. Where in my mind this becomes an “Anti Pattern” is that I should be able to know from looking at the first line what type of visitor this guy is.
The above reflects more the intention and context for this scenario. I now know that a visitor can have different states without having to know more about the system. This might open more conversation around parts of the system we take for granted where user state might not have entered the conversations before.
Designing the UI via scenarios.
This “Anti Pattern” probably emerged because I have at times added scenarios and automation after implementing the features and relates more to the automation process than conversation and raw BDD. However I still found references to scenarios like:
What this means now is that my automated conversations are now so tightly coupled to the UI that a single design change will break the automation putting it now in the “Technical Debt” category.
More importantly this scenario has now isolated non technical people from the conversation. We need to speak a common language and having implementation details and specifics in the scenarios hinders the open clear communication channel.
Automation over Conversation.
This is probably the biggest of my “Anti Patterns”. I am a developer and I enjoy using BDD tools, After looking at the scenarios and grouping them into logical categories for essential automation and non essential I found that at times I have favoured automation over just having a conversation with the business.
I think its hard to find a balance on when to use automation to validate the scenario but the most important lesson to learn here is that we need the conversation way before we even look at what tools we can use to automate it.
Example being, I found lots of little feature files around setting configuration values in Magento ( all basic system settings for currency, ownership details, address ) However because these were just tasks that I had to complete I never took the small amount of time required to talk to the business and see what value doing this added. I should have spent the time I used automating the behavour testing to just ask: What address shall we set as default ? Will this ever change based on X Y or Z…
I did find a few other areas that I can improve upon, but I dont think that these are worthy of falling into “Anti Patterns”. All of the above are just my findings from what was my work so they might not be more common anti patterns but I would love to hear feedback from others to see if they can related to the above.
You may also find these related posts interesting: Developer Book Club All hail Xdebug and lets let var dump die A new look and a cleanup of content plus good bye github pages. Docker and Docker Sync