Banner background image: Comet P/Halley as taken March 8, 1986 by W. Liller, Easter Island, part of the International Halley Watch (IHW) Large Scale Phenomena Network.
NASA/W. Liller – NSSDC’s Photo Gallery (NASA) http://nssdc.gsfc.nasa.gov/photo_gallery/photogallery-comets.html
http://nssdc.gsfc.nasa.gov/image/planetary/comet/lspn_comet_halley1.jpg
This post was inspired by a discussion I had on this twitter thread:
I’m proposing a new term such as BDA (Behaviour Driven Automation) or something similar to be introduced to classify the testing and automation part of the BDD process so that discussions and advancements in this space can progress unhindered by “That’s not BDD” commentary.
Say you are building a web application and have adopted a BDD practice and your team has authored some Gherkin features that describe intended behaviour in a declarative manner with steps that conform to all the prescribed BDD rules.
What follows is based on my work on the open source Gwen project. It is not a BDD process by any means but rather what I have been calling BDA (A for Automation). Similar could potentially be done with other tooling.
At some point you will want to use some features “as is” to automate some testing. Gwen enables you to do exactly this by mapping the declarative Gherkin in your features to imperative Gherkin that you define in separate meta files. The Gherkin in these meta files must conform to the prescribed Gwen Web DSL. This meta has nothing to do with BDD but everything to do with web automation and assertion checking which is all necessary imperative behaviour. When you invoke Gwen, it will bind your features to your meta at runtime and execute them for you to achieve automation. So you don’t have to develop any page objects, selenium code or test framework. You just compose some Gherkin meta to describe the automation behaviour.
That’s BDA. Your declarative BDD features are executable and remain untouched.