All the Gwen user documentation is now available on our new home page at https://gweninterpreter.org/. We’ve put in a lot of work to make it more user friendly.
Checkout the new Gwen Introduction.
We’re just wrapping up Gwen 3 too which will make it easy to add Gwen to JS projects with npm.
Stay tuned!
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.
Simpler web automation.
A Java runtime, a web browser, your favourite text editor, and the Gwen interpreter is all you need to start automating.
No clickety-click drag-drop mouse-pointy UI or dev-centric page-object code-compiling IDE or plugin required.
The interpreter is open source.
The automation is reusable, scalable, and shareable.
Many execution modes including sequential, parallel, dry run, and interactive REPL are provided.
Many reporting formats including JUnit XML, cucumber JSON, and pretty HTML are supported.
JavaScript can be injected in places if needed.
A CLI makes it easy to run locally and integrate with any on-premise or on-cloud build server.
Git ready workspaces make it easy for teams to collaborate.
A package manager downloads and installs native browser drivers for you.
Built on Gherkin and Selenium.
Easy to run on BrowserStack, Sauce Labs, Aerokube Selenoid and other grids.
Matured in industry for over 4 years.
Active user community is growing.
Gwen home page: http://gweninterpreter.org
Share with your friends.
Feedback welcomed.
Gwen is first and foremost a BDA tool. BDD on the other hand has its purpose but it’s not automation. It’s a development practice. But it turns out that behavior in prose can be used to drive automation.
When you use behavioral specifications to drive automation of any kind, you are doing BDA. Be it for testing, robotic process automation (RPA) or any other purpose. It does not matter!
It just so happens that in BDD you are doing it to test-first at development time. In the case of test-later and also RPA, you are doing it after development time. Gwen can be used to transform behavioral specifications into automation operations in any case.
Gwen is about making behavior driven automation easier for everyone.
Core Gwen Interpreter
Web automation engine
Gwen workspace are deprecated in favour of JS projects in Gwen 3!
In this post I’m going to walk though the basics of getting a Gwen Workspace up and running on Jenkins.
Be sure you have following setup before proceeding..
Next, you will need to convert your Gwen project over to a Gwen Workspace. If you have not already done this it is easy to do. Just follow these steps:
.feature and .meta files to the features foldergwen features -b in the workspace root
The benefit of using a workspace is that it contains an embedded Gwen Package Manager that will automatically install and configure Gwen for you (so you don’t have to do this manually in the Jenkins environment). If you do not want to use a workspace but would rather utilise your current project setup “as is”, then you will have to do manual installation and configuration work on the Jenkins host to ensure that your features can execute (but the basic setting up of the Jenkins job will be similar to below).
Once you have a workspace that is accessible from Git, you are ready to create a Jenkins job to run your workspace.
./gwen features -b -f junit -Dgwen.web.browser.headless=truegwen features -b -f junit -Dgwen.web.browser.headless=true-b tells Gwen to exit once execution is complete, -f junit tells Gwen to generate JUnit-XML reports, and -Dgwen.web.browser.headless=true tells Gwen to run the browser in headless mode. You can also pass additional Gwen options if required, like --parallel for example if you want to utilise all cores and perform parallel execution.
target/reports/junit/TEST-*.xmlThat’s it!!
Gwen workspace are deprecated in favour of JS projects in Gwen 3!
Manually setting up and installing Gwen on multiple machines or build servers in a team environment can be tedious and can also result in inconsistent configurations across workstations. One of the reasons why we created gwen-gpm was to provide consistent installation across machines and platforms. But a team needs more than that. A team needs a consistent and seamless way of getting Gwen configured and running on any user workstation or build server too.
Gwen workspaces solve this problem by defining a standard project structure on the file system complete with settings files and wrapper scripts that can easily be committed to Git and checked out on any machine. Any team member can then just checkout the workspace and start using Gwen straight away. Gwen will be automatically downloaded and installed on any user workstation or build server if not already present (through an embedded Gwen package manager in the workspace).
It is assumed that the target browser is already installed on the system. If not, you will need to manually install it.
The structure of this workspace is defined as follows:
gwen-workspace |--/env : Put environment properties here |--/features : Put your Gherkin feature and common meta files here | gwen : Gwen launcher/wrapper script for linux | gwen.bat : Gwen launcher/wrapper script for windows | gwen.properties : Common Gwen properties | log4j.properties : Gwen log settings | gwen-gpm.jar : Gwen package manager | .gitignore : Git ignore fileCreate and Commit a Workspace to Git
To create a Gwen workspace for your team, perform the following (only one person in the team needs to do this):
gwen (on windows) or ./gwen (on linux). Type exit when done to quit the REPL session.To use the workspace on any machine, perform the following (all team members need to do this):
gwen (on windows) or ./gwen (on linux) followed by the options you requireexit when done to quit the REPL session (if you started Gwen in REPL mode).The team can now manage all their Gwen settings, environment configurations, Gherkin feature files, and Gwen meta files in a single workspace that can easily be pulled down and executed on any machine.
For help, open a command prompt in the workspace root and type:
gwen help (on windows platforms)./gwen help (on linux platforms)Each folder in the workspace also includes a README.txt file that can help to guide you.
Gwen Interpreter 
