From a business perspective, feature specifications should be declarative. What does does this mean? It means that features should describe the intended behavior of a feature independently of any implementation details (especially automation details). They should clearly express behavior in business terms and may also include some examples.
Imperative specifications on the other hand consist of a step by step list of statements that describe a behavior in great detail and that can be followed robotically to emulate a process. You would ideally never write features in this manner when describing business specifications.
Declarative to Imperative Automation Bindings
Gwen is a Gherkin interpreter that was designed with behavior driven automation (BDA) in mind. It enables teams to bind declarative business features “as is” to imperative meta features to drive automation. Meta features are used to describe (or break down) declarative features into step definitions and bindings that can be used to drive automated testing and robotic processing. In Gwen, they are also defined in the Gherkin language and bind to declarative features at run time to make them executable.
Reuse can be maximised by sharing common meta across features
In the test-first approach, the team would first write feature specifications and then use those to drive development and automated testing at the same time. Executing features with Gwen prior to development would result in failures (as expected). As the feature is being implemented in code, the developers and/or testers can write meta features to define all the necessary step definitions and bindings. Loading the meta and executing features with Gwen during development would then enable the test execution to run. By progressively building up the required meta during development, the feature tests will eventually pass when implementation is complete.
In the test-later approach, Gherkin features can be used to drive user acceptance testing after the development is complete. New acceptance features can be written if desired at this stage. Any meta that was created during development (if the test-first approach was practiced) could be reused here. Otherwise all the necessary step definitions and bindings will need to be defined in meta during this phase. The meta can then be loaded into Gwen to make the acceptance features perform the test execution.
Robotic process automation (RPA) involves the repeatable execution of tasks that would otherwise need to be performed by humans. A repetitive or monotonous process performed online by a person, for example, can be automated with Gwen by writing Gherkin specifications that describe that behavior. These too can be declarative with imperative bindings in meta, but can also be imperative only.
We have open sourced a web engine (Selenium wrapper) for Gwen that you can use to perform any sort of web UI automation using the approaches described above. But Gwen is not limited to just web automation. Many types of Gwen engines can be built and shared. We are currently developing a REST engine for API testing and automation.
More on Gwen
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
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..
- A running Jenkins environment with
- Java 1.8+ installed
- A browser installed (preferably Chrome)
Create a Gwen Workspace Repository
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:
- Download and unzip the latest gwen-workspace.zip to a location on your drive
- Copy all your
.meta files to the
- Copy any common Gwen meta files required by all features to the
meta folder (optional)
- Check that your features execute successfully by running
gwen features -b in the workspace root
- You can tweak any Gwen properties or wrapper scripts in the workspace if required to tailor your execution.
- Publish your workspace folder to your Git repository
The benefit of using a workspace is that it contains an embedded Gwen Package Manager that will automatically install Gwen and any native web drivers 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).
Create a Jenkins Job
Once you have a workspace that is accessible from Git, you are ready to create a Jenkins job to run your workspace.
- Logon to your Jenkins
- Create a new “Freestyle” project and give it a name
- In the “Source Code Management” section, select “Git” and provide your Gwen workspace repository URL and other Git settings
- In the “Build” section, select “Execute Shell” (for linux) or “Execute Windows Batch Command” (for windows), and enter the following command to run Gwen
./gwen features -b -f junit -Dgwen.web.browser.headless=true
gwen 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.
- In the “Post-build Actions” section, select “Publish JUnit test result report”, and enter the following in the “Test Report XMLs” field.
- Click “Save” when you are done and then run your job
Setting up Gwen for teams just got a whole lot easier!
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.
Introducing Gwen workspaces
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 and the native web drivers will be automatically downloaded and installed on any user workstation or build server if they are 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 wrapper script installs Gwen and native drivers but not the browser itself.
The structure of this workspace is defined as follows:
|--/env : Put environment properties here
|--/features : Put your Gherkin feature files here
|--/meta : Put your Gwen 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.properties : Downloadable package checksums
| gwen-gpm.jar : Gwen package manager
| .gitignore : Git ignore file
Create 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):
- Download and extract the latest gwen-workspace.zip to a location on your file system. (Also have a read of the README.txt file that is extracted in the root).
- Tweak or add team wide settings to the gwen.properties file in the workspace root. You can also tailor the wrapper scripts if necessary (for example, if you want to change the default Gwen launch options or add some new ones).
- Verify that it all works by launching
gwen (on windows) or
./gwen (on linux). Type
exit when done to quit the REPL session.
- Commit and push the workspace to your remote Git repository (see online Git help if you are not sure how to do this)
Checkout Workspace from Git and Go..
To use the workspace on any machine, perform the following (all team members need to do this):
- Ensure that the target browser is installed on the system
- Checkout the workspace from Git
- Open a command prompt to the root workspace location
gwen (on windows) or
./gwen (on linux) followed by the options you require
- Gwen will execute using the settings in the workspace
Note: this same command can be used on any build server that checks out the workspace too
- Gwen and native web drivers will self install on the first call
exit 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.
We’re starting to put up some videos on the Gwen YouTube channel here..
There’s also a conference video here that I presented at DOTC Melbourne 2017 (my first ever conference talk where I was a little nervous but thankfully the demo Gods were on my side)..
Gwen just got a package manager that you can use to consistently manage your installations of the following packages across platforms:
- Gwen packages
- Native web drivers
- Java libraries
The primary benefits of using this when working with Gwen include:
- All downloads and installs are managed for you
- You can easily update to the latest versions of packages
- You can easily switch between versions of packages
- All downloads are verified for integrity before they are installed
- Installation is consistent across platforms
Read all about it here and check it out. We’ve just released version 1.0.0. Please provide feedback so we can address any issues and make it better.
With the recent addition of Data Tables and Doc Strings, Gwen now supports the full Gherkin syntax! We’ve also enhanced the REPL console with a paste mode to enable multi-line step evaluation. The latest web engine has been released with all the new capabilities.
This is a major milestone for Gwen. Thank you to all the users who raised issues or requests and to everyone who evaluated the web engine and provided feedback. It really helps us to keep making Gwen better when we hear from you. 🙂