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
- No Page Objects – There’s no long way to go. We’re already there!
- Page Objects Begone
- Automation by Meta
- Gwen Automation with Data Tables
- On Github