One Gwen Interpreter, Many Evaluation Engines

There is so much more that can be automated with Gherkin.

In the previous post, I announced the open sourcing of the gwen-interpreter project. In this post I will introduce the interpreter and evaluation engine concepts and describe the difference and relationship between them.

The Gwen interpreter translates Gherkin features into executable code. The code that each step is translated to is not defined in the interpreter itself, but rather in separate modules called evaluation engines. When a feature is executed, the interpreter delegates the processing of each step to a mixed in engine that you define or provide. This is necessary since evaluation varies across systems and it would be futile to try and code for every conceivable behavior in one implementation. For this reason Gwen abstracts the evaluation engine to support many implementations. In this way, you decide which engine to use based on the type of system you want to evaluate. For example, if you want to evaluate the behavior of a web application, then you can use our web engine. Each engine must prescribe a DSL and use at least one API to interact with a target system.

Engines can be defined to replicate any software process that is reproducible through one or more API’s.

There are many useful engines that can be built and they need not all be confined to just testing. Engines can be defined to automate, emulate, or simulate any process that is repeatable through software. Engines can also be built to generate data and other resources too.

In summary,

• The interpreter reads Gherkin features and dispatches the processing of each step to a mixed in engine.
• Engines define the DSL and processing to create conditions, perform actions, and assert expectations on target systems.

Hopefully many engines will emerge from the community and be shared.

Gwen – A Gherkin DSL Interpreter

One platform for many types of automation.

Gherkin is a language for describing software behavior. Any software behavior. It makes sense to use it for evaluating software behavior too. But how can one evaluate any software behavior against any system with the one language?

A common language interpreter with an abstracted evaluation engine could be one way to do it.

This interpreter would accept Gherkin features as input and produce executing instructions as output. Specialised engines with specifically prescribed DSLs could be built and mixed in. The interpreter would support sequential or parallel execution. It would also produce evaluation reports and have a REPL console. It would provide all the necessary processing and tooling required to interpret Gherkin features and execute them. A public library of engines would emerge and be shared for everyone to download and use. The one interpreter would work with all of them.

It’s a simple idea that a colleague and I have been working on. We wrote it in Scala and open sourced it as a project called gwen.

• https://github.com/gwen-interpreter/gwen

Check it out and have a play. We have released several stable versions of our web engine here: https://github.com/gwen-interpreter/gwen-web/releases