I recently came across a great discussion between Alan Shimel, Grigori Melnik and James Bach on Digital Anarchist. The conversation went from testing in the 60s all the way to present day and time. Very interesting, critical of the status quo and thought provoking. I can only recommend to watch it. In any case, I walked away with one thing that stuck with me. At one point James said – I am paraphrasing – “methods like BDD and related tools are constraining testers too much”. James said it in context of comparing testing tools to development IDEs. Nonetheless is there truth in his view? Is BDD perhaps constraining testers too much?
Let’s look at 4 reasons I can envision that may drove James to his stance on BDD.
1- Have we forgotten about the discovery part in BDD?
Yes Given-When-Then, which a lot of people associate synonymously with BDD, feels like a strict very descriptive model to follow. However, this is not the only aspect of BDD. Deliberate Discovery aims to capture different views and scenarios that might get overlooked by an individual. This is where we are creative, we explore and critically ask ourselves as many “what if” questions as we can that then translate into specification and examples. Discovery takes place before we formalize our findings in our well-known Given-When-Then structure for the purpose of documentation and future automation.
2- Is it worth having a Domain Specific Language (e.g. Gherkin)?
First, we need to remind ourselves on what BDD is really trying to accomplish. It aims to bring all team members together to talk in a unified language about what is supposed to get built by the team. Like any language (natural or not) it serves the purpose to communicate, to align, to instruct, to plan or to collaborate. As we can observe again with natural language just as easily as with artificial languages aligning can be very difficult if people don’t understand each other due to different lingo, dialects and tone. After all we are humans and the same thing that makes us strive – individual interpretation – is also what can lead to false software (according to another person’s view). So normalizing people onto a common language and syntax can help alleviate misunderstandings.
3- Is it worth documenting your intended behavior?
With agile leading the charge of dropping overhead as much as possible we need to ask ourselves is it still necessary to be so tedious about documenting intended system behavior. My answer to this is – as often in life – it depends. Project size, project character, compliance requirements, industry regulations and more are all factors influencing this answer. One thing is clear though small one-off projects will likely not justify it, but for how long can you guarantee that your project will stay this way and what do you do if it suddenly doesn’t? As we can see documentation is – for the time being and, in most situations, – a necessity. All you can try to do is to make it easier and be smarter about it. And this is where I see BDD making a positive impact in the right direction. Concepts like Living Documentation and the application of Gherkin allows to at least reduce the amount of times similar information needs to be differently presented and written until all stakeholders involved from design, to creation to operations of the software have enough information to work with.
4- A Clash of schools of thought
In one of James’s earlier blog posts he states his stance towards very descriptive test design and the importance of human interpretation. The example James gives highlights very well how futile the quest to provide extremely descriptive tests truly is. On the other hand, how do we collaborate as a team (especially distributed) if we don’t define what we or someone else are going to do? Yes, we can collect evidence after we have done “it” and document our endeavors this way. However, most of us that have tried this out will conclude that people forget more in the heat of the moment than they would if they had spent some thought on what they want to do before the action starts. So just jumping right in can’t be it – back to at least a bit of planning and the issue of coming up with some description. And what is the best way to organize the information? Given-When-Then provides us with a structure to sort our thoughts and frankly where in life is a description (even the very laws our countries run on) 100% bullet proof? Never! We use the information for context and then interpret what actions it should or should not allow.
Still, James has a point. A world in which testing is free of constraints and a represents a creative plain field is an enjoyable vision. Something all testers should look forward to and strive to be performing at. Testing should be a creative exercise. Even when testers are applying methodology to their craft, they should never give up their creative mindset and bring this explorative attitude into their teams working style. BDD and creativity don’t exclude each other. I believe they complement each other very well. Particularly the most mature BDD projects will enjoy the freedom to fully embrace creativity in discovery and through exploratory testing.